Re: Panic after updating

On 1/12/21 9:33 AM, Jakob Alvermark wrote:
>
> 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.
>
Alright, after a new bisect run I got a different result, so I most 
likely did something wrong the first time.

ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad commit
commit ff3468ac94597efdcbc56f372528dfc98b114dac
Author: Ian Lepore <ian_at_FreeBSD.org>
Date:   Sat Dec 12 18:34:15 2020 +0000

     Provide userland notification of gpio pin changes ("userland gpio 
interrupts").


Maybe more likely this is causing the panic?


Jakob