Re: Panic on shutdown with Pi2B for May 2026 stabilization week
Mark Millard <[email protected]> Sun, 26 Jul 2026 22:01:10 -0700
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
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. 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. > > Thanks for reading, > > bob prohaska > > > -- === Mark Millard marklmi at yahoo.com