https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #20 from Masachika ISHIZUKA ---
(In reply to Alexander Motin from comment #18)
Thank you for patch.
This patch applied to master-n253798-8cdecdecb43 solves my problem.
--
You are receiving this mail because:
You are the assign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
Alexander Motin changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #19 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=fd6ca665d206b74970e7c01d06ae06fed71500fc
commit fd6ca665d206b74970e7c01d06ae06fed71500fc
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254915
Kubilay Kocak changed:
What|Removed |Added
Keywords||needs-qa
Severity|Affect
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #12 from Aleksander Slomka ---
(In reply to Ed Maste from comment #11)
Thank you for the help! The patch indeed solves the issue for me. Now the
`ioctl` properly returns `EINVAL`:
31415 test CALL ioctl(0x3,SNDCTL_MIXERIN
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262710
Bug ID: 262710
Summary: glabel labels should not be created for snapshots of
zvols
Product: Base System
Version: 12.3-RELEASE
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262215
f...@cantconnect.ru changed:
What|Removed |Added
Status|New |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262709
Yuri Victorovich changed:
What|Removed |Added
Assignee|b...@freebsd.org|toolch...@freebsd.org
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262709
Bug ID: 262709
Summary: Build on arm64 fails with undefined symbol: .mcount
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #18 from Alexander Motin ---
OK. I still don't understand how can it be safe to change the lock when there
seems to be a window between umtxq_getchain() and mtx_lock() inside the
umtxq_lock(), but what would you say about this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262590
--- Comment #9 from Matteo Riondato ---
(In reply to Kristof Provost from comment #8)
We don't end up with "anchor parent", we end up with "parent", rather than with
"parent/*": anchor_call does not include the "anchor " part, as far as I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #17 from Dmitry Chagin ---
Hi, Alexander! Yes, umtxq_requeue() relies on previous behaviour of
umtxq_sleep(), where the lock dropped and reacquired, as umtxq_requeue()
replaces the lock.
A year ago, we discussed this block with
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262708
Bug ID: 262708
Summary: Root on ZFS - GEOM_LABEL issues
Product: Base System
Version: 13.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Aff
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #16 from Mark Johnston ---
(In reply to Alexander Motin from comment #15)
The lock can change if umtxq_requeue() moves the queue to a different hash
chain.With PDROP, the subsequent umtxq_lock(&uq->uq_key) will lock the new
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261005
Kamille Kunde changed:
What|Removed |Added
CC||majoni...@gmail.com
--- Comment #2
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #15 from Alexander Motin ---
Dmitry, I've removed both PDROP and following umtxq_lock(&uq->uq_key). Is lock
changes somehow during the msleep()? I guessed it was made separate to move
umtx_abs_timeout_update() out of the lock.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262706
Yuri Victorovich changed:
What|Removed |Added
Assignee|b...@freebsd.org|toolch...@freebsd.org
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262706
Bug ID: 262706
Summary: Build on arm64 fails to find
libclang_rt.asan-aarch64.a
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
Mark Johnston changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #14 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #13 from Dmitry Chagin ---
hi, it seems the problem in the latest mav@ change to umtxq_sleep(), ie,
call to msleep() without PDROP flag.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #12 from Dmitry Chagin ---
hi, it seems the problem in the latest mav@ change to umtxq_sleep(), ie,
call to msleep() without PDROP flag.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262638
--- Comment #5 from Mark Johnston ---
(In reply to John F. Carr from comment #4)
This looks like it'd work, but it's hard for a reader to understand where the
value of HPET_MEM_MIN_WIDTH comes from. Why not make it just large enough to
rea
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262590
--- Comment #8 from Kristof Provost ---
(In reply to Matteo Riondato from comment #7)
That doesn't look right, no.
It strips the trailing '/*', so we end up with 'anchor "parent"' rather than
'anchor "parent/*"', which doesn't seem like wh
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262698
Ed Maste changed:
What|Removed |Added
CC||ema...@freebsd.org
--- Comment #5 from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #11 from Ed Maste ---
If this is readily reproducible for you could you please give the attached
patch a try?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #10 from Ed Maste ---
Created attachment 232613
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232613&action=edit
possible patch
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262671
--- Comment #9 from Ed Maste ---
(In reply to Aleksander Slomka from comment #8)
Indeed; trying successive mi.dev values here is fine:
#include
#include
#include
#include
#include
int
main()
{
int fd;
fd = open("/dev
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #11 from Mark Johnston ---
Created attachment 232612
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=232612&action=edit
proposed patch
Please give this patch a try. I only compile-tested it.
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213045
--- Comment #20 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=8518513d2436386bb16dac9f344679c2a9b75634
commit 8518513d2436386bb16dac9f344679c2a9b75634
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #10 from Mark Johnston ---
There is an instance of FUTEX_CMP_REQUEUE (op 132). This operation moves
sleeping threads from one umtx queue to another, possibly changing the queue
keys in the process. This is implemented by umtx_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262587
--- Comment #9 from Mark Johnston ---
Hmm, so we were in linux_futex_wait(), presumably having slept (op 137 or 128
are present in the dmesg, but aren't the last ops, last op 129 is a wakeup).
We locked the chain before sleeping, and upon
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213045
--- Comment #19 from Ed Maste ---
(In reply to mikhail.maximov from comment #18)
Sorry, I mean also without running `kldload vesa`.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262215
--- Comment #5 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=bb53dd56c30c6360fc82be762ed98b0af6b9f69f
commit bb53dd56c30c6360fc82be762ed98b0af6b9f69f
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262698
Graham Perrin changed:
What|Removed |Added
CC||grahamper...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262698
--- Comment #3 from dmilith ---
I use this host as a build-host for my software bundles… so the last 3 days it
was building packages, nothing else.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262698
--- Comment #2 from dmilith ---
Here the same system after reboot:
```
last pid: 1163; load averages: 0.20, 0.35, 0.24
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262698
--- Comment #1 from dmilith ---
Also please note that the system has 4G total RAM, so that "used" amount is
significant. A kernel memory leak maybe?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262698
Bug ID: 262698
Summary: Weirdly high memory usage without anything running in
the system
Product: Base System
Version: 13.0-RELEASE
Hardware: Any
OS:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262663
Dave Cottlehuber changed:
What|Removed |Added
Component|bin |kern
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262663
--- Comment #2 from Dave Cottlehuber ---
trying revert of:
commit eb8dcdeac22daadbf07be81d7338e14ec4cc7d7f
Author: Gleb Smirnoff
Date: Sun Dec 26 10:45:50 2021 -0800
jail: network epoch protection for IP address lists
Now stru
40 matches
Mail list logo
