Date: Tue, 12 Jan 2021 12:32:54 +0100 From: Jakob Alvermark <jakob@alvermark.net> To: Hans Petter Selasky <hps@selasky.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Panic after updating Message-ID: <af76d2fc-cc6f-4ca4-c293-ae1ff8f2a51d@alvermark.net> In-Reply-To: <60e4db60-c816-463e-0e08-a33c674ad4da@alvermark.net> References: <87512669-f0b9-eb2f-1103-170a29384ea8@alvermark.net> <ad969a6e-4029-b85c-f304-1198b05ad725@selasky.org> <34a9dafd-9690-1b33-abf8-017ad31cf2ab@alvermark.net> <e407413b-730a-d60d-f50d-0b6f490da74a@selasky.org> <60e4db60-c816-463e-0e08-a33c674ad4da@alvermark.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
>
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?af76d2fc-cc6f-4ca4-c293-ae1ff8f2a51d>