Re: Panic on shutdown with Pi2B for May 2026 stabilization week

On 7/27/26 07:35, bob prohaska wrote:
> On Sun, Jul 26, 2026 at 10:01:10PM -0700, Mark Millard wrote:
>> On 7/26/26 19:59, bob prohaska wrote:
>>> On Mon, May 25, 2026 at 08:25:57PM -0700, Gleb Smirnoff wrote:
>>>>
>>>> No need for apologies. The stabweek is always a good reason to focus
>>>> on old bugs as well :)
>>>>
>>>> -- 
>>>
>>> Alas, the panic on shutdown persists even at
>>> FreeBSD www.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #55 n287675-95439b803fce: Sun Jul 26 17:30:39 PDT 2026     [email protected]:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm armv7 1600019 1600019
>>>
>>> On the console it reports:
>>> ....
>>> Terminated
>>> Jul 26 19:49:12 www syslogd: exiting on signal 15
>>> Waiting (max 60 seconds) for system process `vnlru' to stop... done
>>> Waiting (max 60 seconds) for system process `syncer' to stop... 
>>> Syncing disks, vnodes remaining... 0 done
>>> All buffers synced.
>>> Uptime: 2m35s
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> ue0: link state changed to DOWN
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smsc0: warning: MII is busy
>>> smsc0: warning: Failed to read register 0x114
>>> smscphy0: detached
>>> smsc0: warning: MII is busy
>>> Kernel page faultmiibus0: detached
>>>  with the following non-sleepable locks held:
>>> exclusive sleep mutex smsc0 (smsc0) r = 0 (0xd6796770) locked @ /usr/src/sys/dev/usb/net/if_smsc.c:665
>>> stack backtrace:
>>> #0 0xc03a4734 at witness_debugger+0x78
>>> #1 0xc03a60a0 at witness_warn+0x4a4
>>> #2 0xc06911bc at abort_handler+0x1fc
>>> #3 0xc066f04c at exception_exit+0
>>> #4 0xc00dbb2c at smscphy_status+0x80
>>> #5 0xc00dba94 at smscphy_service+0x21c
>>> #6 0xc00d43c0 at mii_pollstat+0x60
>>> #7 0xc01c58dc at smsc_ifmedia_sts+0x44
>>> #8 0xc047ebcc at ifmedia_ioctl+0x198
>>> #9 0xc055bb04 at dump_iface+0x11c
>>> #10 0xc055b8dc at rtnl_handle_iflink+0xac
>>> #11 0xc0476068 at do_link_state_change+0x1e4
>>> #12 0xc0395b38 at taskqueue_run_locked+0x1c4
>>> #13 0xc0395938 at taskqueue_run+0x50
>>> #14 0xc02db778 at ithread_loop+0x264
>>> #15 0xc02d7450 at fork_exit+0xa0
>>> #16 0xc066efe0 at swi_exit+0
>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read
>>> trapframe: 0xd37d0b28
>>> FSR=00000005, FAR=deadc0de, spsr=60000013
>>> r0 =0000003d, r1 =71b802e7, r2 =71b802e7, r3 =00000000
>>> r4 =d69f6680, r5 =00000000, r6 =deadc0de, r7 =deadc0de
>>> r8 =d6765580, r9 =c096e804, r10=00000000, r11=d37d0bd8
>>> r12=d37d0ad4, ssp=d37d0bb8, slr=c01c3a3c, pc =c00dbb2c
>>>
>>> panic: Fatal abort
>>> cpuid = 2
>>> time = 1785120554
>>> KDB: stack backtrace:
>>> db_trace_self() at db_trace_self
>>>          pc = 0xc066c6b4  lr = 0xc007a2dc (db_trace_self_wrapper+0x40)
>>>          sp = 0xd37d0900  fp = 0xd37d0a18
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x40
>>>          pc = 0xc007a2dc  lr = 0xc0325bd4 (vpanic+0x15c)
>>>          sp = 0xd37d0a20  fp = 0xd37d0a40
>>>          r4 = 0x00000100  r5 = 0xc076b177
>>>          r6 = 0xc0bce484  r7 = 0x00000000
>>> vpanic() at vpanic+0x15c
>>>          pc = 0xc0325bd4  lr = 0xc0325a78 (vpanic)
>>>          sp = 0xd37d0a48  fp = 0xd37d0a4c
>>>          r4 = 0xd37d0b28  r5 = 0x00000013
>>>          r6 = 0xdeadc0de  r7 = 0x00000005
>>>          r8 = 0x00000005  r9 = 0x00000013
>>>         r10 = 0xdeadc0de
>>> vpanic() at vpanic
>>>          pc = 0xc0325a78  lr = 0xc0691898 (abort_align)
>>>          sp = 0xd37d0a54  fp = 0xd37d0a80
>>>          r4 = 0x00000005  r5 = 0x00000005
>>>          r6 = 0x00000013  r7 = 0xdeadc0de
>>>          r8 = 0xd37d0a4c  r9 = 0xc0325a78
>>>         r10 = 0xd37d0a54
>>> abort_align() at abort_align
>>>          pc = 0xc0691898  lr = 0xc06911e8 (abort_handler+0x228)
>>>          sp = 0xd37d0a88  fp = 0xd37d0b20
>>>          r4 = 0xc4c0bc00 r10 = 0xdeadc0de
>>> abort_handler() at abort_handler+0x228
>>>          pc = 0xc06911e8  lr = 0xc066f04c (exception_exit)
>>>          sp = 0xd37d0b28  fp = 0xd37d0bd8
>>>          r4 = 0xd69f6680  r5 = 0x00000000
>>>          r6 = 0xdeadc0de  r7 = 0xdeadc0de
>>>          r8 = 0xd6765580  r9 = 0xc096e804
>>>         r10 = 0x00000000
>>> exception_exit() at exception_exit
>>>          pc = 0xc066f04c  lr = 0xc01c3a3c (smsc_miibus_readreg+0x84)
>>>          sp = 0xd37d0bb8  fp = 0xd37d0bd8
>>>          r0 = 0x0000003d  r1 = 0x71b802e7
>>>          r2 = 0x71b802e7  r3 = 0x00000000
>>>          r4 = 0xd69f6680  r5 = 0x00000000
>>>          r6 = 0xdeadc0de  r7 = 0xdeadc0de
>>>          r8 = 0xd6765580  r9 = 0xc096e804
>>>         r10 = 0x00000000 r12 = 0xd37d0ad4
>>> smscphy_status() at smscphy_status+0x80
>>>          pc = 0xc00dbb2c  lr = 0xc00dba94 (smscphy_service+0x21c)
>>>          sp = 0xd37d0be0  fp = 0xd37d0c00
>>>          r4 = 0x00000003  r5 = 0xd69f6680
>>>          r6 = 0xd703af20  r7 = 0xc077adc5
>>>          r8 = 0x00000000  r9 = 0xc09cabf8
>>>         r10 = 0x00000000
>>> smscphy_service() at smscphy_service+0x21c
>>>          pc = 0xc00dba94  lr = 0xc00d43c0 (mii_pollstat+0x60)
>>>          sp = 0xd37d0c08  fp = 0xd37d0c18
>>>          r4 = 0xd6765580  r5 = 0xd69f6680
>>>          r6 = 0xd703af20  r7 = 0xc077adc5
>>>          r8 = 0x00000000  r9 = 0xc09cabf8
>>>         r10 = 0x00000000
>>> mii_pollstat() at mii_pollstat+0x60
>>>          pc = 0xc00d43c0  lr = 0xc01c58dc (smsc_ifmedia_sts+0x44)
>>>          sp = 0xd37d0c20  fp = 0xd37d0c30
>>>          r4 = 0xd37d0c70  r5 = 0xd6796780
>>>          r6 = 0xd6765580 r10 = 0x00000000
>>> smsc_ifmedia_sts() at smsc_ifmedia_sts+0x44
>>>          pc = 0xc01c58dc  lr = 0xc047ebcc (ifmedia_ioctl+0x198)
>>>          sp = 0xd37d0c38  fp = 0xd37d0c48
>>>          r4 = 0xd37d0c70  r5 = 0x00000000
>>>          r6 = 0xd6765580  r7 = 0x00000020
>>> ifmedia_ioctl() at ifmedia_ioctl+0x198
>>>          pc = 0xc047ebcc  lr = 0xc055bb04 (dump_iface+0x11c)
>>>          sp = 0xd37d0c50  fp = 0xd37d0cc0
>>>          r4 = 0xd37d0cd0  r5 = 0xd67d2400
>>>          r6 = 0xd37d0c70  r7 = 0xdb92d024
>>> dump_iface() at dump_iface+0x11c
>>>          pc = 0xc055bb04  lr = 0xc055b8dc (rtnl_handle_iflink+0xac)
>>>          sp = 0xd37d0cc8  fp = 0xd37d0d18
>>>          r4 = 0xd67d2400  r5 = 0xd37d0cd0
>>>          r6 = 0x00000000  r7 = 0xd39ab880
>>>          r8 = 0x00000001  r9 = 0x00000000
>>>         r10 = 0xd69e0be0
>>> rtnl_handle_iflink() at rtnl_handle_iflink+0xac
>>>          pc = 0xc055b8dc  lr = 0xc0476068 (do_link_state_change+0x1e4)
>>>          sp = 0xd37d0d20  fp = 0xd37d0d48
>>>          r4 = 0xd67d2400  r5 = 0xc07c16ee
>>>          r6 = 0xd39ab89c r10 = 0xd69e0be0
>>> do_link_state_change() at do_link_state_change+0x1e4
>>>          pc = 0xc0476068  lr = 0xc0395b38 (taskqueue_run_locked+0x1c4)
>>>          sp = 0xd37d0d50  fp = 0xd37d0da0
>>>          r4 = 0xd3866600  r5 = 0xd3866650
>>>          r6 = 0xd67d24f8  r7 = 0x00000001
>>>          r8 = 0x00000000  r9 = 0xc07cd7d4
>>>         r10 = 0x00000000
>>> taskqueue_run_locked() at taskqueue_run_locked+0x1c4
>>>          pc = 0xc0395b38  lr = 0xc0395938 (taskqueue_run+0x50)
>>>          sp = 0xd37d0da8  fp = 0xd37d0db0
>>>          r4 = 0xd3866650  r5 = 0xd3866600
>>>          r6 = 0xd3850000  r7 = 0xd39a5880
>>>          r8 = 0x00000000  r9 = 0xc07acbb0
>>>         r10 = 0xd3850008
>>> taskqueue_run() at taskqueue_run+0x50
>>>          pc = 0xc0395938  lr = 0xc02db778 (ithread_loop+0x264)
>>>          sp = 0xd37d0db8  fp = 0xd37d0e18
>>>          r4 = 0x00000000  r5 = 0xd3850044
>>> ithread_loop() at ithread_loop+0x264
>>>          pc = 0xc02db778  lr = 0xc02d7450 (fork_exit+0xa0)
>>>          sp = 0xd37d0e20  fp = 0xd37d0e38
>>>          r4 = 0xd37d0e40  r5 = 0xc4c0bc00
>>>          r6 = 0xc02db514  r7 = 0xc4c0a3a0
>>>          r8 = 0xd3a0d140  r9 = 0x00000000
>>>         r10 = 0x00000000
>>> fork_exit() at fork_exit+0xa0
>>>          pc = 0xc02d7450  lr = 0xc066efe0 (swi_exit)
>>>          sp = 0xd37d0e40  fp = 0x00000000
>>>          r4 = 0xc02db514  r5 = 0xd3a0d140
>>>          r6 = 0x00000000  r7 = 0x00000000
>>>          r8 = 0x00000000 r10 = 0x00000000
>>> swi_exit() at swi_exit
>>>          pc = 0xc066efe0  lr = 0xc066efe0 (swi_exit)
>>>          sp = 0xd37d0e40  fp = 0x00000000
>>> KDB: enter: panic
>>> [ thread pid 11 tid 100013 ]
>>> Stopped at      kdb_enter+0x54: ldrb    r15, [r15, r15, ror r15]!
>>> db> 
>>>
>>> Issuing a reboot command results in a successful restart.
>>> The machine isn't obviously unstable when running buildworld.
>>>
>>> If anybody can suggest things to try I'd be happy to test.
>>
>> There were proposed patches in bugzilla for this that have not been
>> commented on or committed. Specifically for smscphy_status there is:
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290417
>> ("[PATCH] Abort trap at smscphy_status when rebooting")
>> (Reported:	2025-10-22 06:26 UTC by NAKAJI Hiroyuki)
>>
>> The most recent version (v2) of the patch attached goes back to:
>>
>> 2026-01-26 08:39 UTC (Oleksii Samorukov)
>>
>> I've no clue if you ever tried any vintage of the patching.
>>
> 
> The second version (I think!) was tested and avoided the 
> panic on shutdown. I didn't observe any ill effects, and
> backed it out in anticipation that it would be merged in
> good time. 
> 
>> Your:
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292314
>> ("Panic on shutdown -r for current armv7 on raspberry pi 2b")
>> (Reported:	2026-01-10 00:18 UTC by Bob Prohaska)
>>
>> also reports the smscphy_status failure but is not the bugzilla with the
>> patch activity.
>>
>> There may be other patches. I seem to remember that someone tried a
>> common patch instead of per-driver ones but testing showed failures
>> when it was tested.
>>
> 
> I didn't see any failures, but I have only armv7 (RPi2) to test.
> 
> The patch used was:
> bob@www:~ % more alex.patch
> --- b/sys/dev/usb/net/if_smsc.c 
> +++ b/sys/dev/usb/net/if_smsc.c 
> @@ -663,6 +663,12 @@ smsc_ifmedia_sts(if_t ifp, struct ifmediareq *ifmr)
>         struct mii_data *mii = uether_getmii(&sc->sc_ue);
>  
>         SMSC_LOCK(sc);
> +
> +       if (sc->sc_flags & SMSC_FLAG_DETACHING) {
> +               SMSC_UNLOCK(sc);
> +               return;
> +       }
> +
>         mii_pollstat(mii);
>         ifmr->ifm_active = mii->mii_media_active;
>         ifmr->ifm_status = mii->mii_media_status;
> @@ -1813,6 +1819,15 @@ smsc_detach(device_t dev)
>  {
>         struct smsc_softc *sc = device_get_softc(dev);
>         struct usb_ether *ue = &sc->sc_ue;
> +       unsigned i;
> +
> +       SMSC_LOCK(sc);
> +       sc->sc_flags |= SMSC_FLAG_DETACHING;
> +       SMSC_UNLOCK(sc);
> +
> +       /* stop all USB transfers */
> +       for (i = 0; i < SMSC_N_TRANSFER; i++)
> +               usbd_transfer_drain(sc->sc_xfer[i]);
>  
>         usbd_transfer_unsetup(sc->sc_xfer, SMSC_N_TRANSFER);
>         uether_ifdetach(ue);
> --- b/sys/dev/usb/net/if_smscreg.h      
> +++ b/sys/dev/usb/net/if_smscreg.h      
> @@ -267,6 +267,7 @@ struct smsc_softc {
>  
>         uint32_t          sc_flags;
>  #define        SMSC_FLAG_LINK      0x0001
> +#define        SMSC_FLAG_DETACHING 0x0002
>  #define        SMSC_FLAG_LAN9514   0x1000      /* LAN9514 */
>  };
>  

The above is one of the driver specific patches, not one that was more
generic that tried to work at layer(s) that applied to all the relevant
drivers. So I was not reporting any known problems with the above.

> If it caused problems on other platforms that might explain
> the inaction, but I didn't catch on to any.

I've not seen anything reporting any problems with the driver specific
patch --but that does not mean much.

[I'll note that other drivers (not involving smscphy_status) also got
driver specific patches that have not been applied. Same status as far
as I know. The non-patched drivers all looked to have a similar type of
structural problem, as I understand.]

> 
> Thanks for writing!
> 
> bob prohaska
> 
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com