On Thu, Apr 17, 2025 at 05:37:13PM +0800, Zhenlei Huang wrote: > > > > On Apr 17, 2025, at 5:17 AM, Mark Millard <mark...@yahoo.com> wrote: > > > > Context: An aarch64 PkgBase kernel and world boot under Parallels > > on macOS (M4 MAX): > > > > FreeBSD 15.0-CURRENT main-n276258-c5773d366ecc GENERIC arm64 aarch64 1500035 > > > > . . . > > vtnet0: link state changed to UP > > Invoking IPv6 network device address event may sleep with the following > > non-sleepable locks held: > > exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xffffa000c0b3e480) > > locked @ > > /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 > > stack backtrace: > > #0 0xffff000000530f0c at witness_debugger+0x60 > > #1 0xffff000000532140 at witness_warn+0x408 > > #2 0xffff00000069ede8 at in6_update_ifa+0xa68 > > #3 0xffff0000006cbcb0 at in6_ifadd+0x1dc > > #4 0xffff0000006c80f8 at nd6_ra_input+0xe38 > > #5 0xffff000000699200 at icmp6_input+0x900 > > #6 0xffff0000006b2c54 at ip6_input+0xf64 > > #7 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #8 0xffff0000005f58d4 at ether_demux+0x174 > > #9 0xffff0000005f6f80 at ether_nh_input+0x374 > > #10 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #11 0xffff0000005f5d24 at ether_input+0xdc > > #12 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 > > #13 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 > > #14 0xffff00000031f824 at vtpci_intx_intr+0xe8 > > #15 0xffff00000046e0e4 at ithread_loop+0x29c > > #16 0xffff00000046a2b0 at fork_exit+0x78 > > #17 0xffff0000008897f8 at fork_trampoline+0x18 > > lock order reversal: (sleepable after non-sleepable) > > 1st 0xffffa000c0b3e480 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ > > /home/pkgbuild/worktrees/main/sys/dev/virtio/network/if_vtnet.c:2202 > > 2nd 0xffff000001129640 in6_multi_sx (in6_multi_sx, sx) @ > > /home/pkgbuild/worktrees/main/sys/netinet6/in6_mcast.c:1217 > > lock order vtnet0-rx0 -> in6_multi_sx attempted at: > > #0 0xffff000000530aac at witness_checkorder+0xad0 > > #1 0xffff0000004c405c at _sx_xlock+0x70 > > #2 0xffff0000006a7a68 at in6_joingroup+0x48 > > #3 0xffff00000069f01c at in6_update_ifa+0xc9c > > #4 0xffff0000006cbcb0 at in6_ifadd+0x1dc > > #5 0xffff0000006c80f8 at nd6_ra_input+0xe38 > > #6 0xffff000000699200 at icmp6_input+0x900 > > #7 0xffff0000006b2c54 at ip6_input+0xf64 > > #8 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #9 0xffff0000005f58d4 at ether_demux+0x174 > > #10 0xffff0000005f6f80 at ether_nh_input+0x374 > > #11 0xffff000000613a04 at netisr_dispatch_src+0xd8 > > #12 0xffff0000005f5d24 at ether_input+0xdc > > #13 0xffff000000328ea4 at vtnet_rxq_eof+0x6f4 > > #14 0xffff0000003286ec at vtnet_rx_vq_process+0xb0 > > #15 0xffff00000031f824 at vtpci_intx_intr+0xe8 > > #16 0xffff00000046e0e4 at ithread_loop+0x29c > > #17 0xffff00000046a2b0 at fork_exit+0x78 > > Starting Network: lo0 vtnet0. > > . . . > > > > > > === > > Mark Millard > > marklmi at yahoo.com > > > > > > > This is a known ( WIP ) issue. See https://reviews.freebsd.org/D45950 > <https://reviews.freebsd.org/D45950> .
Yes, I got somewhat stuck on figuring out how to deal with the rx taskqueue there. I'm pretty sure it can be removed, but would need to think about it more and do a fair bit of testing.
