Panic: @r323525: iflib

Conrad Meyer cem at freebsd.org
Wed Sep 13 14:20:46 UTC 2017


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 @ /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.


More information about the freebsd-current mailing list