Date: Tue, 12 Jan 2021 18:10:15 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Jakob Alvermark <jakob@alvermark.net>, FreeBSD Current <freebsd-current@freebsd.org>, Ian Lepore <ian@FreeBSD.org> Subject: Re: Panic after updating Message-ID: <e72200ec-3c33-0b8a-90fe-66a969eb8f4a@selasky.org> In-Reply-To: <f3e0ceb9-07ea-0118-645b-47a93085883f@selasky.org> 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> <af76d2fc-cc6f-4ca4-c293-ae1ff8f2a51d@alvermark.net> <75784796-b513-5573-abc4-8c445d03c007@selasky.org> <cdc94c54-6f21-d452-87fd-9b0e5d7cbe95@alvermark.net> <5724744d-7710-4c3c-416b-01314cb196d4@selasky.org> <1bab5b76-eb56-671f-d52d-db1812c9be22@alvermark.net> <f3e0ceb9-07ea-0118-645b-47a93085883f@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/12/21 2:46 PM, Hans Petter Selasky wrote:
> On 1/12/21 2:40 PM, Jakob Alvermark wrote:
>>
>> On 1/12/21 2:16 PM, Hans Petter Selasky wrote:
>>> On 1/12/21 1:43 PM, Jakob Alvermark wrote:
>>>>
>>>> On 1/12/21 12:54 PM, Hans Petter Selasky wrote:
>>>>> On 1/12/21 12:32 PM, Jakob Alvermark wrote:
>>>>>> 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?
>>>>>
>>>>> Doesn't make sense :-(
>>>>>
>>>>> Can you try to fetch the latest 13-current as of now and re-build
>>>>> the kernel? I noticed some issues myself which got fixed.
>>>>
>>>>
>>>> I did that, still panics the same way.
>>>>
>>>> But, the commit above is about gpio, and I do have
>>>> 'bytgpio_load="YES"' in my /boot/loader.conf
>>>>
>>>> If I boot the kernel without that it works.
>>>>
>>>> 'kldload bytgpio' panics the machine.
>>>>
>>>
>>> Could you screenshot the panic backtrace after kldload of bytegpio ?
>>
>> Sure:
>>
>> panic: vm_fault_lookup: fault on nofault entry, addr: 0xfffffe00c96c2000
>> cpuid = 1
>> time = 1610458544
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe00c7306140
>> vpanic() at vpanic+0x181/frame 0xfffffe00c7306190
>> panic() at panic+0x43/frame 0xfffffe00c73061f0
>> vm_fault() at vm_fault+0x142d/frame 0xfffffe00c73062f0
>> vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfffffe00c7306340
>> trap_pfault() at trap_pfault+0x1f6/frame 0xfffffe00c73063a0
>> trap() at trap+0x280/frame 0xfffffe00c73064b0
>> calltrap() at calltrap+0x8/frame 0xfffffe00c73064b0
>> --- trap 0xc, rip = 0xffffffff80c27d08, rsp = 0xfffffe00c7306580, rbp
>> = 0xfffffe00c7306580 ---
>> lock_init() at lock_init+0xf8/frame 0xfffffe00c7306580
>> _mtx_init() at _mtx_init+0x70/frame 0xfffffe00c73065a0
>> gpioc_attach() at gpioc_attach+0x139/frame 0xfffffe00c7306620
>> device_attach() at device_attach+0x3dd/frame 0xfffffe00c7306670
>> bus_generic_attach() at bus_generic_attach+0x4b/frame 0xfffffe00c73066a0
>> gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame 0xfffffe00c73066c0
>> bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfffffe00c7306710
>> device_attach() at device_attach+0x3dd/frame 0xfffffe00c7306760
>> device_probe_and_attach() at device_probe_and_attach+0x41/frame
>> 0xfffffe00c7306790
>> acpi_driver_added() at acpi_driver_added+0xaa/frame 0xfffffe00c73067c0
>> devclass_driver_added() at devclass_driver_added+0x3c/frame
>> 0xfffffe00c7306800
>> devclass_add_driver() at devclass_add_driver+0x13d/frame
>> 0xfffffe00c7306840
>> module_register_init() at module_register_init+0xa7/frame
>> 0xfffffe00c7306870
>> linker_load_module() at linker_load_module+0xbca/frame 0xfffffe00c7306b80
>> kern_kldload() at kern_kldload+0xbb/frame 0xfffffe00c7306bd0
>> sys_kldload() at sys_kldload+0x5b/frame 0xfffffe00c7306c00
>> amd64_syscall() at amd64_syscall+0x111/frame 0xfffffe00c7306d30
>> fast_syscall_common() at fast_syscall_common+0xf8/frame
>> 0xfffffe00c7306d30
>> --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a, rsp
>> = 0x7fffffffe698, rbp = 0x7fffffffec10 ---
>> KDB: enter: panic
>>
>
> Adding Ian.
>
Looks like an off-by-one there.
Can you try to apply this patch manually:
> diff --git a/sys/dev/gpio/gpioc.c b/sys/dev/gpio/gpioc.c
> index 727b07a7058..29d795bb54b 100644
> --- a/sys/dev/gpio/gpioc.c
> +++ b/sys/dev/gpio/gpioc.c
> @@ -582,7 +582,7 @@ gpioc_attach(device_t dev)
> return (err);
> sc->sc_pin_intr = malloc(sizeof(struct gpioc_pin_intr) * sc->sc_npins,
> M_GPIOC, M_WAITOK | M_ZERO);
> - for (int i = 0; i <= sc->sc_npins; i++) {
> + for (int i = 0; i != sc->sc_npins; i++) {
> sc->sc_pin_intr[i].pin = malloc(sizeof(struct gpiobus_pin),
> M_GPIOC, M_WAITOK | M_ZERO);
> sc->sc_pin_intr[i].sc = sc;
> @@ -616,7 +616,7 @@ gpioc_detach(device_t dev)
> if (sc->sc_ctl_dev)
> destroy_dev(sc->sc_ctl_dev);
>
> - for (int i = 0; i <= sc->sc_npins; i++) {
> + for (int i = 0; i != sc->sc_npins; i++) {
> mtx_destroy(&sc->sc_pin_intr[i].mtx);
> free(&sc->sc_pin_intr[i].pin, M_GPIOC);
> }
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e72200ec-3c33-0b8a-90fe-66a969eb8f4a>