Re: Panic after updating

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));
>  }

And:

git show de0b2d4f47bad36025dcf52755ce76cca6e715d9 | patch -p1 -R

gets you a working kernel?

--HPS