Re: Panic after updating

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
>> _at__at_ -367,7 +367,7 _at__at_ 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