The poudriere build machine building amd64 packages also panicked. But with:
Dumping 2577 out of 8122 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91 % __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:59 59 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu , (kgdb) #0 __curthread () at /opt/src/git-src/sys/amd64/include/pcpu_aux.h:5 9 #1 doadump (textdump=textdump@entry=1) at /opt/src/git-src/sys/kern/kern_shutdown.c:407 #2 0xffffffff806c10e0 in kern_reboot (howto=260) at /opt/src/git-src/sys/kern/kern_shutdown.c:528 #3 0xffffffff806c15df in vpanic ( fmt=0xffffffff80b6c5f5 "%s: possible deadlock detected for %p (%s), blocked for %d ticks\n", ap=ap@entry=0xfffffe008e698e90) at /opt/src/git-src/sys/kern/kern_shutdown.c:972 #4 0xffffffff806c1383 in panic (fmt=<unavailable>) at /opt/src/git-src/sys/kern/kern_shutdown.c:896 #5 0xffffffff8064a5ea in deadlkres () at /opt/src/git-src/sys/kern/kern_clock.c:201 #6 0xffffffff80677632 in fork_exit (callout=0xffffffff8064a2c0 <deadlkres>, arg=0x0, frame=0xfffffe008e698f40) at /opt/src/git-src/sys/kern/kern_fork.c:1162 #7 <signal handler called> (kgdb) This is consistent with PR/271945. Reducing -J to 1 or 5:1 circumvents this panic. This is certainly a different panic from the one experienced on the poudriere builder building i386 packages. Both machines run in amd64 mode. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0 Cy Schubert writes: > This is new. Instead of affecting the machine with poudriere building amd64 > packages, it affected the other machine with poudriere building i386 > packages. This is new since the two recent ZFS patches. > > Don't get me wrong, the two new patches have resulted in I believe better > availability of the poudriere machine building amd64 packages. I doubt the > two patches caused this but they may have exposed this problem, probably > fixed by another patch or two. > > Sorry, there was no dump produced by this panic. I'll need to check the > config of this machine, swap is a gmirror, which it doesn't like to dump > to. Below are serial console messages captured by conserver. > > panic: vm_page_dequeue_deferred: page 0xfffffe00028fb0d0 has unexpected > queue state^M > cpuid = 3^M > time = 1691807572^M > KDB: stack backtrace:^M > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00c50bc600^M > vpanic() at vpanic+0x132/frame 0xfffffe00c50bc730^M > panic() at panic+0x43/frame 0xfffffe00c50bc790^M > vm_page_dequeue_deferred() at vm_page_dequeue_deferred+0xb2/frame > 0xfffffe00c50bc7a0^M > vm_page_free_prep() at vm_page_free_prep+0x11b/frame 0xfffffe00c50bc7c0^M > vm_page_free_toq() at vm_page_free_toq+0x12/frame 0xfffffe00c50bc7f0^M > vm_object_page_remove() at vm_object_page_remove+0xb6/frame > 0xfffffe00c50bc850^M > vn_pages_remove_valid() at vn_pages_remove_valid+0x48/frame > 0xfffffe00c50bc880^M > zfs_rezget() at zfs_rezget+0x35/frame 0xfffffe00c50bca60^M > zfs_resume_fs() at zfs_resume_fs+0x1c8/frame 0xfffffe00c50bcab0^M > zfs_ioc_rollback() at zfs_ioc_rollback+0x157/frame 0xfffffe00c50bcb00^M > zfsdev_ioctl_common() at zfsdev_ioctl_common+0x612/frame > 0xfffffe00c50bcbc0^M > zfsdev_ioctl() at zfsdev_ioctl+0x12a/frame 0xfffffe00c50bcbf0^M > devfs_ioctl() at devfs_ioctl+0xd2/frame 0xfffffe00c50bcc40^M > vn_ioctl() at vn_ioctl+0xc2/frame 0xfffffe00c50bccb0^M > devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe00c50bccd0^M > kern_ioctl() at kern_ioctl+0x286/frame 0xfffffe00c50bcd30^M > sys_ioctl() at sys_ioctl+0x152/frame 0xfffffe00c50bce00^M > amd64_syscall() at amd64_syscall+0x138/frame 0xfffffe00c50bcf30^M > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00c50bcf30^M > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x20938296107a, rsp = > 0x209379aeee18, rbp = 0x209379aeee90 ---^M > Uptime: 42m33s^M > Automatic reboot in 15 seconds - press a key on the console to abort^M > Rebooting...^M > cpu_reset: Restarting BSP^M > cpu_reset_proxy: Stopped CPU 3^M > > > -- > Cheers, > Cy Schubert <cy.schub...@cschubert.com> > FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org > NTP: <c...@nwtime.org> Web: https://nwtime.org > > e^(i*pi)+1=0 > > > Cy Schubert writes: > > I haven't experienced any problems (yet) either. > > > > > > -- > > Cheers, > > Cy Schubert <cy.schub...@cschubert.com> > > FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org > > NTP: <c...@nwtime.org> Web: https://nwtime.org > > > > e^(i*pi)+1=0 > > > > > > In message <CAK7dMtDJQtaai3_6VjEkwVwW5JN6e8v=kKTOPffp371xb=ORUg@mail.gmail. > c > > om> > > , Kevin Bowling writes: > > > The two MFVs on head have improved/fixed stability with poudriere for > > > me 48 core bare metal. > > > > > > On Thu, Aug 10, 2023 at 6:37=E2=80=AFAM Cy Schubert <Cy.Schubert@cschuber > t. > > = > > > com> wrote: > > > > > > > > In message <cak7dmtdjeuf8rjwbsnezabufeqpjuychzuol9aahkk93sy+...@mail.gm > ai > > = > > > l.c > > > > om> > > > > , Kevin Bowling writes: > > > > > Possibly https://github.com/openzfs/zfs/commit/2cb992a99ccadb78d97049 > b4 > > = > > > 0bd4=3D > > > > > 42eb4fdc549d > > > > > > > > > > On Tue, Aug 8, 2023 at 10:08=3DE2=3D80=3DAFAM Dag-Erling Sm=3DC3=3DB8 > rg > > = > > > rav <des@freeb=3D > > > > > sd.org> wrote: > > > > > > > > > > > > At some point between 42d088299c (4 May) and f0c9703301 (26 June), > a > > > > > > deadlock was introduced in ZFS. It is still present as of 9c2823ba > e9 > > = > > > (4 > > > > > > August) and is 100% reproducable just by starting poudriere bulk in > a > > > > > > 16-core VM and waiting a few hours until deadlkres kicks in. In th > e > > > > > > latest instance, deadlkres complained about a bash process: > > > > > > > > > > > > #0 sched_switch (td=3D3Dtd@entry=3D3D0xfffffe02fb1d8000, flags > = > > > =3D3Dflags@e=3D > > > > > ntry=3D3D259) at /usr/src/sys/kern/sched_ule.c:2299 > > > > > > #1 0xffffffff80b5a0a3 in mi_switch (flags=3D3Dflags@entry=3D3D > 25 > > = > > > 9) at /u=3D > > > > > sr/src/sys/kern/kern_synch.c:550 > > > > > > #2 0xffffffff80babcb4 in sleepq_switch (wchan=3D3D0xfffff81854 > 3a > > = > > > 9e70, =3D > > > > > pri=3D3D64) at /usr/src/sys/kern/subr_sleepqueue.c:609 > > > > > > #3 0xffffffff80babb8c in sleepq_wait (wchan=3D3D<unavailable>, > p > > = > > > ri=3D3D<=3D > > > > > unavailable>) at /usr/src/sys/kern/subr_sleepqueue.c:660 > > > > > > #4 0xffffffff80b1c1b0 in sleeplk (lk=3D3Dlk@entry=3D3D0xfffff8 > 18 > > = > > > 543a9e70=3D > > > > > , flags=3D3Dflags@entry=3D3D2121728, ilk=3D3Dilk@entry=3D3D0x0, wmesg > = > > > =3D3Dwmesg@entry=3D > > > > > =3D3D0xffffffff8222a054 "zfs", pri=3D3D<optimized out>, pri@entry=3D3 > D6 > > = > > > 4, timo=3D3D=3D > > > > > timo@entry=3D3D6, queue=3D3D1) at /usr/src/sys/kern/kern_lock.c:310 > > > > > > #5 0xffffffff80b1a23f in lockmgr_slock_hard (lk=3D3D0xfffff818 > 54 > > = > > > 3a9e70=3D > > > > > , flags=3D3D2121728, ilk=3D3D<optimized out>, file=3D3D0xffffffff8125 > 44 > > = > > > fb "/usr/s=3D > > > > > rc/sys/kern/vfs_subr.c", line=3D3D3057, lwa=3D3D0x0) at /usr/src/sys/ > ke > > = > > > rn/kern_=3D > > > > > lock.c:705 > > > > > > #6 0xffffffff80c59ec3 in VOP_LOCK1 (vp=3D3D0xfffff818543a9e00, > f > > = > > > lags=3D > > > > > =3D3D2105344, file=3D3D0xffffffff812544fb "/usr/src/sys/kern/vfs_subr > .c > > = > > > ", line=3ÀÀÀÀÀÀÀÀÀ > > > > > =3D3D3057) at ./vnode_if.h:1120 > > > > > > #7 _vn_lock (vp=3D3Dvp@entry=3D3D0xfffff818543a9e00, flags=3D3 > D2 > > = > > > 105344, fi=3D > > > > > le=3D3D<unavailable>, line=3D3D<unavailable>, line@entry=3D3D3057) at > / > > = > > > usr/src/sy=3D > > > > > s/kern/vfs_vnops.c:1815 > > > > > > #8 0xffffffff80c4173d in vget_finish (vp=3D3D0xfffff818543a9e0 > 0, > > = > > > flags=3D > > > > > =3D3D<unavailable>, vs=3D3Dvs@entry=3D3DVGET_USECOUNT) at /usr/src/sy > s/ > > = > > > kern/vfs_s=3D > > > > > ubr.c:3057 > > > > > > #9 0xffffffff80c1c9b7 in cache_lookup (dvp=3D3Ddvp@entry=3D3D0 > xf > > = > > > ffff802c=3D > > > > > d02ac40, vpp=3D3Dvpp@entry=3D3D0xfffffe046b20ac30, cnp=3D3Dcnp@entry= > 3D > > = > > > 3D0xfffffe04=3D > > > > > 6b20ac58, tsp=3D3Dtsp@entry=3D3D0x0, ticksp=3D3Dticksp@entry=3D3D0x0) > a > > = > > > t /usr/src/s=3D > > > > > ys/kern/vfs_cache.c:2086 > > > > > > #10 0xffffffff80c2150c in vfs_cache_lookup (ap=3D3D<optimized o > ut > > = > > > >) at =3D > > > > > /usr/src/sys/kern/vfs_cache.c:3068 > > > > > > #11 0xffffffff80c32c37 in VOP_LOOKUP (dvp=3D3D0xfffff802cd02ac4 > 0, > > = > > > vpp=3D > > > > > =3D3D0xfffffe046b20ac30, cnp=3D3D0xfffffe046b20ac58) at ./vnode_if.h: > 69 > > > > > > #12 vfs_lookup (ndp=3D3Dndp@entry=3D3D0xfffffe046b20abd8) at /u > sr > > = > > > /src/sys=3D > > > > > /kern/vfs_lookup.c:1266 > > > > > > #13 0xffffffff80c31ce1 in namei (ndp=3D3Dndp@entry=3D3D0xfffffe > 04 > > = > > > 6b20abd8=3D > > > > > ) at /usr/src/sys/kern/vfs_lookup.c:689 > > > > > > #14 0xffffffff80c52090 in kern_statat (td=3D3D0xfffffe02fb1d800 > 0, > > = > > > flag=3D > > > > > =3D3D<optimized out>, fd=3D3D-100, path=3D3D0xa75b480e070 <error: Can > no > > = > > > t access m=3D > > > > > emory at address 0xa75b480e070>, pathseg=3D3Dpathseg@entry=3D3DUIO_US > ER > > = > > > SPACE, s=3D > > > > > bp=3D3Dsbp@entry=3D3D0xfffffe046b20ad18) > > > > > > at /usr/src/sys/kern/vfs_syscalls.c:2441 > > > > > > #15 0xffffffff80c52797 in sys_fstatat (td=3D3D<unavailable>, ua > p= > > > =3D3D0xff=3D > > > > > fffe02fb1d8400) at /usr/src/sys/kern/vfs_syscalls.c:2419 > > > > > > #16 0xffffffff