On 1/12/21 6:10 PM, Hans Petter Selasky wrote: > 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_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? >>>>>> >>>>>> 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 >> _at__at_ -582,7 +582,7 _at__at_ 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; >> _at__at_ -616,7 +616,7 _at__at_ 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); >> } Yes! That works! Thank you! JakobReceived on Wed Jan 13 2021 - 06:15:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC