Panic after updating
Jakob Alvermark
jakob at alvermark.net
Tue Jan 12 08:33:30 UTC 2021
On 1/11/21 7:08 PM, Hans Petter Selasky wrote:
> On 1/11/21 5:24 PM, Jakob Alvermark wrote:
>>
>> On 1/11/21 1:14 PM, Hans Petter Selasky wrote:
>>> On 1/11/21 11:12 AM, Jakob Alvermark wrote:
>>>>
>>>> Updated my Acer laptop from r367734 to main-c255666-g1790f5e654f
>>>>
>>>>
>>>> Rebooting with the newly build kernel i get this panic.
>>>>
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>>
>>>> cpuid = 1; apic id = 02
>>>> fault virtual address = 0x1030000
>>>> fault code = supervisor read data,
>>>>
>>>> instruction pointer = 0x20:0xffffffff809e5265
>>>> stack pointer = 0x28:0xffffffff8281db70
>>>> frame pointer = 0x28:0xffffffff8281db70
>>>> code segment = base 0x0, limit 0xfffff, type 0x1b
>>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>>> processor eflags = interrupt enabled, resume, IOPL = 0
>>>> current process = 12 (irq88: xhci0)
>>>> trap number = 12
>>>> panic: page fault
>>>> cpuid = 1
>>>> time = 2
>>>> KDB: stack backtrace:
>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>> 0xffffffff8281d820
>>>> vpanic() at vpanic+0x181/frame 0xffffffff8281d870
>>>> panic() at panic+0x43/frame 0xffffffff8281d8d0
>>>> trap_fatal() at trap_fatal+0x387/frame 0xffffffff8281d930
>>>> trap_pfault() at trap_pfault+0x4f/frame 0xffffffff8281d990
>>>> trap() at trap+0x280/frame 0xffffffff8281daa0
>>>> calltrap() at calltrap+0x8/frame 0xffffffff8281daa0
>>>> --- trap 0xc, rip = 0xffffffff809e5265, rsp =
>>>> 0xffffffff8281db70, rbp = 0xffffffff8281db70 ---
>>>> usbd_get_page() at usbd_get_page+0x65/frame 0xffffffff8281db70
>>>> xhci_interrupt_poll() at xhci_interrupt_poll+0x29/frame
>>>> 0xffffffff8281dc20
>>>> xhci_interrupt() at xhci_interrupt+0x11a/frame 0xffffffff8281dc60
>>>> ithread_loop() at ithread_loop+0x24f/frame 0xffffffff8281dcf0
>>>> fork_exit() at fork_exit+0x7e/frame 0xffffffff8281dd30
>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xffffffff8281dd30
>>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>>> KDB: enter: panic
>>>>
>>>>
>>>> Any help appreciated.
>>>
>>> Hi,
>>>
>>> If you could bi-sect that panic, would be great.
>>>
>>> Else install gdb from ports and run:
>>>
>>> kgdb101
>>>
>>> info line *(usbd_get_page+0x65)
>>>
>>>
>>
>> Having just learned how to bisect (thanks Warner for the mini primer)
>> this is the result:
>>
>> de0b2d4f47bad36025dcf52755ce76cca6e715d9 is the first bad commit
>>
>
> You mean this commit is causing the panic?
>
>> git show de0b2d4f47bad36025dcf52755ce76cca6e715d9
>> commit de0b2d4f47bad36025dcf52755ce76cca6e715d9
>> Author: Mateusz Guzik <mjg at FreeBSD.org>
>> Date: Sun Dec 13 21:30:42 2020 +0000
>>
>> Patch annotation in sigdeferstop
>> Probability flipped since sigdefer handling was moved away
>> from regular VOP
>> calls.
>>
>> Notes:
>> svn path=/head/; revision=368616
>>
>> diff --git a/sys/sys/signalvar.h b/sys/sys/signalvar.h
>> index 93ef15bbbf0..df761a1e1a5 100644
>> --- a/sys/sys/signalvar.h
>> +++ b/sys/sys/signalvar.h
>> @@ -367,7 +367,7 @@ static inline int
>> sigdeferstop(int mode)
>> {
>>
>> - if (__predict_true(mode == SIGDEFERSTOP_NOP))
>> + if (__predict_false(mode == SIGDEFERSTOP_NOP))
>> return (SIGDEFERSTOP_VAL_NCHG);
>> return (sigdeferstop_impl(mode));
>> }
It appears so. Mind you, this is the first time I have done a bisect, I
may have made a mistake.
>
> And:
>
> git show de0b2d4f47bad36025dcf52755ce76cca6e715d9 | patch -p1 -R
>
> gets you a working kernel?
>
No... So I probably made a mistake in bisecting. I will try again.
Jakob
More information about the freebsd-current
mailing list