Panic after updating
Ian Lepore
ian at freebsd.org
Tue Jan 12 18:45:52 UTC 2021
On Tue, 2021-01-12 at 18:10 +0100, 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
> > @@ -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
>
If that is the problem, I'd rather see it fixed by using the idiomatic
i < sc->sc_npins rather than the non-standard != test. (But I don't
feel strongly enough about it to learn how to use git and commit the
fix myself.)
-- Ian
More information about the freebsd-current
mailing list