Re: Kernel panic: gpioctl list + odroid-c1
> On May 10, 2022, at 8:46 PM, Brook Milligan wrote:
>
> One more piece of information.
>
> src/sys/arch/arm/amlogic/meson8b_pinctrl.c includes the following code:
>
> static const struct meson_pinctrl_gpio meson8b_cbus_gpios[] = {
>
> … < deleted sections > …
>
> /* GPIODV */
> CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
> CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
> CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),
> CBUS_GPIO(GPIODV_27, 6, 27, 0, 27),
> CBUS_GPIO(GPIODV_28, 6, 28, 0, 28),
> CBUS_GPIO(GPIODV_29, 6, 29, 0, 29),
>
> It seems that GPIODV_9 does not occur in the second list; I would have
> expected it to the be first entry. Is there a reason for it to be missing?
>
> Could this be the cause of the panic?
Further along: the short answer is yes. The following patch fixes the
immediate problem of the panic, although I have no idea if the data here are
correct; I’m just following the pattern of the other entries.
Index: meson8b_pinctrl.c
===
RCS file: /cvsroot/src/sys/arch/arm/amlogic/meson8b_pinctrl.c,v
retrieving revision 1.2
diff -u -r1.2 meson8b_pinctrl.c
--- meson8b_pinctrl.c 14 Aug 2019 09:50:20 - 1.2
+++ meson8b_pinctrl.c 11 May 2022 13:08:29 -
@@ -226,6 +226,7 @@
CBUS_GPIO(GPIOY_14, 3, 14, 3, 14),
/* GPIODV */
+ CBUS_GPIO(GPIODV_9, 6, 9, 0, 9),
CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),
I would appreciate confirmation that the data this patch adds to the lookup
table is correct.
Clearly, however, there is a hidden problem somewhere else in the code. This
is a lookup table; the pin number (or potentially name) is the key. Almost
certainly, the problem was a missing entry causing the lookup to not match
anything. The presumably bogus information returned led to the panic. This
means that somewhere else in the code is lookup logic that is not detecting the
“missing key” case, which means that there are potential panics lurking in the
future whenever a table like this is incomplete. Unfortunately, I have no idea
where that lookup code is; ideas?
Unless I hear otherwise, I will commit this patch sometime soon. In the
meantime, I would appreciate feedback.
Thanks a lot.
Cheers,
Brook
Re: Kernel panic: gpioctl list + odroid-c1
> On May 10, 2022, at 8:06 PM, Brook Milligan wrote:
>
> I have encountered a totally repeatable kernel panic by running "gpioctl
> list” on an odroid-c1 board.
>
> # name -a
> NetBSD armv7 9.99.96 NetBSD 9.99.96 (GENERIC) #0: Mon May 2 10:50:02 UTC
> 2022 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC
> evbarm
>
> To investigate, I added some printf() to the gpiolist() function to see what
> was happening in the loop through the pins. Here is a bit of the output:
>
> # ./gpioctl2 gpio0 list
> gpioctl.c::gpiolist()
> gpioctl.c::gpiolist(): gpio_npins=71
> gpioctl.c::gpiolist(): gpio_pin 0
> 0: gp_pin=0
> 0: gp_value=1
> 0: gp_name=GPIOX_0
> gpioctl.c::gpiolist(): gpio_pin 1
> 1: gp_pin=1
> 1: gp_value=1
> 1: gp_name=GPIOX_1
>
> … < lots of pin output deleted > …
>
> gpioctl.c::gpiolist(): gpio_pin 29
> 29: gp_pin=29
> 29: gp_value=1
> 29: gp_name=GPIOY_14
> gpioctl.c::gpiolist(): gpio_pin 30
> [ 33.9588550] panic: divide by 0
> [ 33.9588550] cpu0: Begin traceback...
> [ 33.9588550] 0xbd7cdbd4: netbsd:db_panic+0x14
> [ 33.9677710] 0xbd7cdbf4: netbsd:vpanic+0x114
> [ 33.9677710] 0xbd7cdc0c: netbsd:panic+0x24
> [ 33.9761750] 0xbd7cdc2c: netbsd:__aeabi_idiv0+0x18
> [ 33.9822960] 0xbd7cdc4c: netbsd:meson_pinctrl_pin_read+0x88
> [ 33.9822960] 0xbd7cdcec: netbsd:gpioioctl+0x4f4
> [ 33.9902860] 0xbd7cdd24: netbsd:spec_ioctl+0x60
> [ 33.9902860] 0xbd7cdd54: netbsd:VOP_IOCTL+0x50
> [ 33.9991180] 0xbd7cde24: netbsd:vn_ioctl+0xd8
> [ 34.0057320] 0xbd7cdeec: netbsd:sys_ioctl+0x47c
> [ 34.0057320] 0xbd7cdfac: netbsd:syscall+0x188
> [ 34.0135450] cpu0: End traceback...
> Stopped in pid 214.214 (gpioctl2) atnetbsd:cpu_Debugger+0x4:bx
>
> r14
> db{0}>
One more piece of information.
src/sys/arch/arm/amlogic/meson8b_pinctrl.c includes the following code:
/*
* GPIO banks. The values must match those in dt-bindings/gpio/meson8b-gpio.h
*/
enum {
… < deleted sections > …
GPIODV_9 = 30,
GPIODV_24,
GPIODV_25,
GPIODV_26,
GPIODV_27,
GPIODV_28,
GPIODV_29,
… < more deleted sections > …
};
… < deleted sections > …
static const struct meson_pinctrl_gpio meson8b_cbus_gpios[] = {
… < deleted sections > …
/* GPIODV */
CBUS_GPIO(GPIODV_24, 6, 24, 0, 24),
CBUS_GPIO(GPIODV_25, 6, 25, 0, 25),
CBUS_GPIO(GPIODV_26, 6, 26, 0, 26),
CBUS_GPIO(GPIODV_27, 6, 27, 0, 27),
CBUS_GPIO(GPIODV_28, 6, 28, 0, 28),
CBUS_GPIO(GPIODV_29, 6, 29, 0, 29),
It seems that GPIODV_9 does not occur in the second list; I would have expected
it to the be first entry. Is there a reason for it to be missing?
Could this be the cause of the panic?
Cheers,
Brook
Kernel panic: gpioctl list + odroid-c1
I have encountered a totally repeatable kernel panic by running "gpioctl list”
on an odroid-c1 board.
# name -a
NetBSD armv7 9.99.96 NetBSD 9.99.96 (GENERIC) #0: Mon May 2 10:50:02 UTC 2022
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/evbarm/compile/GENERIC evbarm
To investigate, I added some printf() to the gpiolist() function to see what
was happening in the loop through the pins. Here is a bit of the output:
# ./gpioctl2 gpio0 list
gpioctl.c::gpiolist()
gpioctl.c::gpiolist(): gpio_npins=71
gpioctl.c::gpiolist(): gpio_pin 0
0: gp_pin=0
0: gp_value=1
0: gp_name=GPIOX_0
gpioctl.c::gpiolist(): gpio_pin 1
1: gp_pin=1
1: gp_value=1
1: gp_name=GPIOX_1
… < lots of pin output deleted > …
gpioctl.c::gpiolist(): gpio_pin 29
29: gp_pin=29
29: gp_value=1
29: gp_name=GPIOY_14
gpioctl.c::gpiolist(): gpio_pin 30
[ 33.9588550] panic: divide by 0
[ 33.9588550] cpu0: Begin traceback...
[ 33.9588550] 0xbd7cdbd4: netbsd:db_panic+0x14
[ 33.9677710] 0xbd7cdbf4: netbsd:vpanic+0x114
[ 33.9677710] 0xbd7cdc0c: netbsd:panic+0x24
[ 33.9761750] 0xbd7cdc2c: netbsd:__aeabi_idiv0+0x18
[ 33.9822960] 0xbd7cdc4c: netbsd:meson_pinctrl_pin_read+0x88
[ 33.9822960] 0xbd7cdcec: netbsd:gpioioctl+0x4f4
[ 33.9902860] 0xbd7cdd24: netbsd:spec_ioctl+0x60
[ 33.9902860] 0xbd7cdd54: netbsd:VOP_IOCTL+0x50
[ 33.9991180] 0xbd7cde24: netbsd:vn_ioctl+0xd8
[ 34.0057320] 0xbd7cdeec: netbsd:sys_ioctl+0x47c
[ 34.0057320] 0xbd7cdfac: netbsd:syscall+0x188
[ 34.0135450] cpu0: End traceback...
Stopped in pid 214.214 (gpioctl2) atnetbsd:cpu_Debugger+0x4:bx
r14
db{0}>
I’m guessing this is a device tree problem, given the reference to
meson_pinctl_pin_read(), but I have no idea how the kernel data structure is
created or what to do about this.
For reference, u-boot loads the following device tree before booting the
kernel: meson8b-odroidc1.dtb.
Any thoughts would be greatly appreciated.
Thanks a lot.
Cheers,
Brook
