lock order reversal and poudriere

I am compiling some packages with poudriere on 13-current kernel. I noticed some strange messages printed into the terminal and dmesg: lock order reversal:  1st 0xf8010ca78250 zfs (zfs) @ /usr/src-13/sys/kern/vfs_mount.c:1005  2nd 0xf8010cd37250 devfs (devfs) @ /usr/src-13/sys/kern/vfs_

Re: lock order reversal and poudriere

Hi! > I am compiling some packages with poudriere on 13-current kernel. I > noticed some strange messages printed into the terminal and dmesg: > > lock order reversal: [...] > Are those the debug messages that aren't visible on non-current kernel > and should they be reported? Yes, they should b

Re: lock order reversal and poudriere

On 02/05/2020 10:54, Kurt Jaeger wrote: Hi! I am compiling some packages with poudriere on 13-current kernel. I noticed some strange messages printed into the terminal and dmesg: lock order reversal: [...] Are those the debug messages that aren't visible on non-current kernel and should th

panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

cpuid = 3 time = 1588422616 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b27e86b0 vpanic() at vpanic+0x182/frame 0xfe00b27e8700 panic() at panic+0x43/frame ... sleepq_add() ... I see db> in the terminal. I tried "dump" but it says, Can

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On 02/05/2020 14:15, Grzegorz Junka wrote: cpuid = 3 time = 1588422616 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b27e86b0 vpanic() at vpanic+0x182/frame 0xfe00b27e8700 panic() at panic+0x43/frame ... sleepq_add() ... I see db> in

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

Hi Grzegorz, If you have another machine connected by network that you can install and start netdumpd on, and; ipv4 configured on a supported network device before the machine paniced; and a recent CURRENT; you should be able to initiate a kernel dump over the network with 'netdump -s server-ip' i

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On 02/05/2020 15:40, Conrad Meyer wrote: Hi Grzegorz, If you have another machine connected by network that you can install and start netdumpd on, and; ipv4 configured on a supported network device before the machine paniced; and a recent CURRENT; you should be able to initiate a kernel dump o

Re: lock order reversal and poudriere

Hi! > > > I am compiling some packages with poudriere on 13-current kernel. I > > > noticed some strange messages printed into the terminal and dmesg: > > > > > > lock order reversal: > > [...] > > > Are those the debug messages that aren't visible on non-current kernel > > > and should they be r

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On 02/05/2020 14:56, Grzegorz Junka wrote: On 02/05/2020 14:15, Grzegorz Junka wrote: cpuid = 3 time = 1588422616 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b27e86b0 vpanic() at vpanic+0x182/frame 0xfe00b27e8700 panic() at panic+0x43/

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On Sat, 2 May 2020 20:19:56 +0100 Grzegorz Junka li...@gjunka.com said On 02/05/2020 14:56, Grzegorz Junka wrote: > > On 02/05/2020 14:15, Grzegorz Junka wrote: >> cpuid = 3 >> >> time = 1588422616 >> >> KDB: stack backtrace: >> >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On Sat, May 02, 2020 at 02:56:27PM +0100, Grzegorz Junka wrote: > > On 02/05/2020 14:15, Grzegorz Junka wrote: > > cpuid = 3 > > > > time = 1588422616 > > > > KDB: stack backtrace: > > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe00b27e86b0 > > > > vpanic() at vpani

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On 02/05/2020 20:43, Chris wrote: On Sat, 2 May 2020 20:19:56 +0100 Grzegorz Junka li...@gjunka.com said On 02/05/2020 14:56, Grzegorz Junka wrote: > > On 02/05/2020 14:15, Grzegorz Junka wrote: >> cpuid = 3 >> >> time = 1588422616 >> >> KDB: stack backtrace: >> >> db_trace_self_wrapper() at d

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On 02/05/2020 21:18, Mark Johnston wrote: OK, I found this handbook https://www.freebsd.org/doc/en/books/developers-handbook/book.html#kerneldebug Obviously something must have been misconfigured that I can't dump the core now. Is there anything I can fetch from the system while I am in db> or

Re: panic: Assertion lock == sq->sq_lock failed at /usr/src-13/sys/kern/subr_sleepqueue.c:371

On Sun, 3 May 2020 00:15:48 +0100 Grzegorz Junka li...@gjunka.com said On 02/05/2020 20:43, Chris wrote: > On Sat, 2 May 2020 20:19:56 +0100 Grzegorz Junka li...@gjunka.com said > >> On 02/05/2020 14:56, Grzegorz Junka wrote: >> > >> > On 02/05/2020 14:15, Grzegorz Junka wrote: >> >> cpuid = 3 >

Re: beadm no longer able to destroy, maybe since using OpenZFS

After reverting from OpenZFS to ZFS, I was able to destroy two of the boot environments that previously (below, 1st May, OpenZFS) could not be destroyed. I'm left with at least one BE 'r360237c' that can not be destroyed. Is it ever normal to find a snapshot described as '-'? root@momh167-gj

Re: svn commit: r360233 - in head: contrib/jemalloc . . . : This partially breaks a 2-socket 32-bit powerpc (old PowerMac G4) based on head -r360311

[I'm only claiming the new jemalloc is involved and that reverting avoids the problem.] I've been reporting to some lists problems with: dhclient sendmail rpcbind mountd nfsd getting SIGSEGV (signal 11) crashes and some core dumps on the old 2-socket (1 core per socket) 32-bit PowerMac G4 runnin