Well, we know it's due to r323516, but unfortunately can't have you bisect from there because it was committed as a giant lump. If it can't be fixed quickly, maybe it should be reverted? Best, Conrad On Wed, Sep 13, 2017 at 6:10 AM, David Wolfskill <david_at_catwhisker.org> wrote: > My build machine didn't have the problem -- unfortunately (as I have a > serial console on it). The laptop did.... The panic occurs immediately > after probing the NICs (so the good news is that it didn't have a chance > yet to mount any filesystems; the bad news is that there's no dump > available). (In transcribing the backtrace, I realized that the laptop > has an em(4) device; the build machine does not. And iflib appears to > be implicated.) > > I used my phone to grab screeshots of the backtrace... and the program I > run on the phone to act as an SSH server so I can get the photos from it > has suddenly become completely confused as to what the IP address of the > phone is on the local network (using an unreachable 10/8 address; at > this point, I won't waste my time trying to figure out how THAT broke). > > I did try clearing /usr/obj/usr/src/sys/CANARY/* and rebuilding the > kernel, but the symptom persists. (I am using "WITH_META_MODE=yes".) > > Previous successful build was: > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #398 r323483M/323489:1200044: Tue Sep 12 04:31:08 PDT 2017 root_at_g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > The usual historical information, including a verbose-boot dmesg.boot > from the above-cited build, may be found at > <http://www.catwhisker.org/~david/FreeBSD/history/>. > > I will try hand-transcribing some of the lock & backtrace info: > > ... > em0: allocated for 1 rx_queues > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex taskqgroup (taskqgroup) r = 0 (0xfffffe07be2e4800) locked _at_ /usr/src/sys/kern/subr_gtaskqueue.c:803 > stack backtrace: [which I am abbreviating at this point -- dhw] > #0 ... at witness_debugger+0x73 > #1 ... at witness_warn+0x43f > #2 ... at trap_pfault+0x53 > #3 ... at trap+0x2c5 > #4 ... at calltrap+0x8 > #5 ... at iflib_device_register+0x2a61 > #6 ... at iflib_device_attach+0xb7 > #7 ... at device_attach+0x3ee > #8 ... at bus_generic_attach+0x5a > #9 ... at pci_attach+0xd5 > #10 ... at device_attach+0x3ee > #11 ... at bus_generic_attach+0x5a > #12 ... at acpi_pcib_acpi_attach+0x3bc > #13 ... at device_attach+0x3ee > #14 ... at bus_generic_attach+0x5a > #15 ... at acpi_attach+0xe85 > #16 ... at device_attach+0x3ee > #17 ... at bus_generic_attach+0x5a > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0xffffffff8b530c20 > fault code = supervisor write data, page not present > ... > [ thread pid 0 tid 100000 ] > Stopped at 0xffffffff80a743b0 = taskqgroup_attach+0x230: orq %rax,-0x 58(%rbp,%xrx,8) > > I can provide more specific excerpts, but I need to focus on some > other activities for a while. > > Peace, > david > -- > David H. Wolfskill david_at_catwhisker.org > http://www.cbc.ca/news/opinion/donald-trump-playbook-1.4265374 > > See http://www.catwhisker.org/~david/publickey.gpg for my public key.Received on Wed Sep 13 2017 - 12:20:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:13 UTC