Re: "Duplicated clock registration" panic on -CURRENT

From: Emmanuel Vadot <manu_at_bidouilliste.com>
Date: Wed, 22 Jan 2025 07:49:42 UTC
 Hi Peter,

On Sun, 19 Jan 2025 18:40:49 +1100
Peter Jeremy <peter@rulingia.com> wrote:

> I have an old BananaPi M1 (Allwinner A20, dual-core Cortex-A7) that I
> am trying to upgrade from FreeBSD 14 to FreeBSD 15-CURRENT and got an
> an unexpected panic during boot with my custom kernel.  I tried
> building a GENERIC kernel and got the same.  OTOH, I'm not seeing any
> problems with the same revision on old RaspberryPi 2 (BCM2836).  The
> cause isn't clear to me and I wonder if anyone can suggest where to
> look for the cause.
> 
> FreeBSD 15.0-CURRENT #0 current-c296623-g9d6043f980a2-dirty: Sun Jan 19 18:01:23 AEDT 2025
>     root@rpi2a.rulingia.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
> ...
> panic: Duplicated clock registration: osc32k
> 
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>          pc = 0xc060c7d8  lr = 0xc00752c8 (db_trace_self_wrapper+0x30)
>          sp = 0xc0e14b48  fp = 0xc0e14c60
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>          pc = 0xc00752c8  lr = 0xc02f9468 (vpanic+0x140)
>          sp = 0xc0e14c68  fp = 0xc0e14c88
>          r4 = 0x00000100  r5 = 0x00000000
>          r6 = 0xc07108b4  r7 = 0xc0b45b04
> vpanic() at vpanic+0x140
>          pc = 0xc02f9468  lr = 0xc02f9328 (vpanic)
>          sp = 0xc0e14c90  fp = 0xc0e14c94
>          r4 = 0xd408ea00  r5 = 0xc08e8310
>          r6 = 0xc0775126  r7 = 0xd408ea00
>          r8 = 0xc095f8b8  r9 = 0xc08e8470
>         r10 = 0xd408ea00
> vpanic() at vpanic
>          pc = 0xc02f9328  lr = 0xc008963c (clknode_create+0x134)
>          sp = 0xc0e14c9c  fp = 0xc0e14cf0
>          r4 = 0xd408ea00  r5 = 0xc095f8b8
>          r6 = 0xc08e8470  r7 = 0xd408ea00
>          r8 = 0xc0e14c94  r9 = 0xc02f9328
>         r10 = 0xc0e14c9c
> clknode_create() at clknode_create+0x134
>          pc = 0xc008963c  lr = 0xc008caec (clknode_fixed_register+0x20)
>          sp = 0xc0e14cf8  fp = 0xc0e14d08
>          r4 = 0xd6d05e80  r5 = 0xc095f8b8
>          r6 = 0xd6d05e80  r7 = 0xc095f8e8
>          r8 = 0xc0b351a4  r9 = 0xc33ba7c0
>         r10 = 0x80040003
> clknode_fixed_register() at clknode_fixed_register+0x20
>          pc = 0xc008caec  lr = 0xc0648c64 (aw_rtc_attach+0x1c0)
>          sp = 0xc0e14d10  fp = 0xc0e14d50
>          r4 = 0xd4015b80  r5 = 0xc3330a40
>          r6 = 0xd6d05e80 r10 = 0x80040003
> aw_rtc_attach() at aw_rtc_attach+0x1c0
>          pc = 0xc0648c64  lr = 0xc0338d00 (device_attach+0x5c8)
>          sp = 0xc0e14d58  fp = 0xc0e14da0
>          r4 = 0xd4015b80  r5 = 0xd4017580
>          r6 = 0x387b0459  r7 = 0x00000000
>          r8 = 0xc0bbbf24 r10 = 0x80040003
> device_attach() at device_attach+0x5c8
>          pc = 0xc0338d00  lr = 0xc033b038 (bus_generic_new_pass+0x13c)
>          sp = 0xc0e14da8  fp = 0xc0e14dc0
>          r4 = 0xd4015b80  r5 = 0xc091595c
>          r6 = 0xc0985490  r7 = 0xc075a0c1
>          r8 = 0xc0b53234  r9 = 0xc09849d4
>         r10 = 0xc0b351a8
> bus_generic_new_pass() at bus_generic_new_pass+0x13c
>          pc = 0xc033b038  lr = 0xc033afc4 (bus_generic_new_pass+0xc8)
>          sp = 0xc0e14dc8  fp = 0xc0e14de0
>          r4 = 0xd4017580  r5 = 0xc091595c
>          r6 = 0xc0985490  r7 = 0xc075a0c1
>          r8 = 0xc0b53234 r10 = 0xc0b351a8
> bus_generic_new_pass() at bus_generic_new_pass+0xc8
>          pc = 0xc033afc4  lr = 0xc033afc4 (bus_generic_new_pass+0xc8)
>          sp = 0xc0e14de8  fp = 0xc0e14e00
>          r4 = 0xd4017b00  r5 = 0xc091595c
>          r6 = 0xc0985490  r7 = 0xc075a0c1
>          r8 = 0xc0b53234 r10 = 0xc0b351a8
> bus_generic_new_pass() at bus_generic_new_pass+0xc8
>          pc = 0xc033afc4  lr = 0xc033afc4 (bus_generic_new_pass+0xc8)
>          sp = 0xc0e14e08  fp = 0xc0e14e20
>          r4 = 0xd4017b80  r5 = 0xc091595c
>          r6 = 0xc0985490  r7 = 0xc075a0c1
>          r8 = 0xc0b53234 r10 = 0xc0b351a8
> bus_generic_new_pass() at bus_generic_new_pass+0xc8
>          pc = 0xc033afc4  lr = 0xc033d8a4 (root_bus_configure+0x48)
>          sp = 0xc0e14e28  fp = 0xc0e14e40
>          r4 = 0xc091595c  r5 = 0xd4018000
>          r6 = 0xc0b53234  r7 = 0xd403d9e0
>          r8 = 0xc0b53258 r10 = 0xc0b351a8
> root_bus_configure() at root_bus_configure+0x48
>          pc = 0xc033d8a4  lr = 0xc027dcec (mi_startup+0x228)
>          sp = 0xc0e14e48  fp = 0xc0e14e88
>          r4 = 0xc0b351ac  r5 = 0x03800000
>          r6 = 0xc095c3f4  r7 = 0xc0916094
>          r8 = 0x00000000 r10 = 0xc0b351a8
> mi_startup() at mi_startup+0x228
>          pc = 0xc027dcec  lr = 0xc027dcec (mi_startup+0x228)
>          sp = 0xc0e14e6c  fp = 0xc0e14e88
> KDB: enter: panic
> 
> -- 
> Peter Jeremy

 Looks like the dtb have a node for this fixed clock (see
https://cgit.freebsd.org/src/tree/sys/contrib/device-tree/src/arm/allwinner/sun7i-a20.dtsi#n214)
and we also export a clock in the rtc driver
https://cgit.freebsd.org/src/tree/sys/arm/allwinner/aw_rtc.c#n259
 I think that we shouldn't install the clocks if there is no
clock-output-names property at all.

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>