Re: [Bug 292695] rpi3b+ muge0 panic on shutdown
- Reply: Alex Samorukov : "Re: [Bug 292695] rpi3b+ muge0 panic on shutdown"
- In reply to: Mark Millard : "Re: [Bug 292695] rpi3b+ muge0 panic on shutdown"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 30 Jan 2026 23:59:04 UTC
On Tue, Jan 27, 2026 at 12:19:46PM -0800, Mark Millard wrote:
> On 1/27/26 07:40, bob prohaska wrote:
> > On Mon, Jan 26, 2026 at 07:38:48AM -0800, Mark Millard wrote:
> >> On 1/26/26 07:00, Warner Losh wrote:
> >>>
> >>>
> >>> On Mon, Jan 26, 2026 at 1:41 AM Alex Samorukov <samm@freebsd.org
> >>> <mailto:samm@freebsd.org>> wrote:
> >>>
> >>>
> >>> On 26.01.2026 8:24, Adrian Chadd wrote:
> >>> >> Kindly asking to review and merge if possible,
> >>> >>
> >>> >> https://bz-attachments.freebsd.org/attachment.cgi?id=267455
> >>> <https://bz-attachments.freebsd.org/attachment.cgi?id=267455>
> >>> > hi!
> >>> >
> >>> > Hm! So, is the panic because the callout is running during shutdown?
> >>> > Chances are you want to set the flag early in detach, and then go
> >>> > through the shutdown
> >>> > path of cancel/draining the poll callout, it should catch it 100%
> >>> > without needing the pause!
> >>>
> >>> Hi Adrian. Thank you for review and you absolutely right, USB draining
> >>> eliminates need for the pause
> >>>
> >>> I updated both patches:
> >>>
> >>> https://bugs.freebsd.org/bugzilla/attachment.cgi?
> >>> id=267497&action=diff <https://bugs.freebsd.org/bugzilla/
> >>> attachment.cgi?id=267497&action=diff>
> >>>
> >>> https://bugs.freebsd.org/bugzilla/attachment.cgi?
> >>> id=267496&action=diff <https://bugs.freebsd.org/bugzilla/
> >>> attachment.cgi?id=267496&action=diff>
> >>>
> >>>
> >>> Both those patches look good to me. Adrian?
> >>>
> >>> Warner
> >>
> >> Do any of the other 7 sys/dev/usb/net/if_*.c using mii_pollstat need
> >> similar changes?
> >>
> >> # grep -rl mii_pollstat /usr/src/sys/dev/usb/net/ | sort
> >> /usr/src/sys/dev/usb/net/if_aue.c
> >> /usr/src/sys/dev/usb/net/if_axe.c
> >> /usr/src/sys/dev/usb/net/if_axge.c
> >> /usr/src/sys/dev/usb/net/if_mos.c
> >> /usr/src/sys/dev/usb/net/if_muge.c
> >> /usr/src/sys/dev/usb/net/if_rue.c
> >> /usr/src/sys/dev/usb/net/if_smsc.c
> >> /usr/src/sys/dev/usb/net/if_udav.c
> >> /usr/src/sys/dev/usb/net/if_ure.c
> >>
> >
> > Are there any instances of similar code being used in
> > USB disk-related components of FreeBSD?
>
> Looks like only usb/net/ :
>
> # grep -rl mii_pollstat /usr/src/sys/dev/usb/ | sort
> /usr/src/sys/dev/usb/net/if_aue.c
> /usr/src/sys/dev/usb/net/if_axe.c
> /usr/src/sys/dev/usb/net/if_axge.c
> /usr/src/sys/dev/usb/net/if_mos.c
> /usr/src/sys/dev/usb/net/if_muge.c
> /usr/src/sys/dev/usb/net/if_rue.c
> /usr/src/sys/dev/usb/net/if_smsc.c
> /usr/src/sys/dev/usb/net/if_udav.c
> /usr/src/sys/dev/usb/net/if_ure.c
>
> >
> > At the moment an armv7 Pi2B is apparently stuck in
> > some sort of loop flashing its USB-sata disk activity LED.
> >
> > It was running buildworld but is now unresponsive on
> > both network (ping reports neither error nor reply, just
> > 100% packet loss) and serial console (enter-tilda-control-B
> > elicits no response, restarting tip _and_ its controlling
> > ssh session makes no difference).
> >
> > It's unclear how long this situation has persisted, but I've
> > been watching for close to half an hour and plan to let it
> > go a bit longer in hopes someone has better ideas.
> >
> > Meanwhile a Pi2B v1.1 using a USB-pata disk is continuing
> > to make progress on buildworld. It had a head start and
> > likely remains ahead.
The Pi2B finally finished and is now at
FreeBSD 16.0-CURRENT #6 main-n283373-58580dc0c694: Fri Jan 30 04:41:43 PST 2026
root@:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
It turns out that unplugging the Pi's ethernet connection allows
a normal reboot, no panic. It does not seem necessary to unplug
the ethernet cable before startup, booting with network wired up,
uplugging the RJ-45 and then issuing shutdown -r results in a
clean restart.
I've also tried running init 1 and ifconfig ue0 down, it still
panics during shutdown with ethernet connected.
This seems like a promising clue but I have no idea how to
exploit it. Can anyone suggest experiments?
Thanks for reading,
bob prohaska