Re: [Bug 205166] OS craching on USB connection.

On Sat, Jan 13, 2024 at 11:39:42PM +0000, bugzilla-noreply@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205166
> 
> Warner Losh <imp@FreeBSD.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|New                         |Closed
>                  CC|                            |imp@FreeBSD.org
>          Resolution|---                         |Overcome By Events
> 
> --- Comment #3 from Warner Losh <imp@FreeBSD.org> ---
> This sure looks weird....
> However, it's against a version of FreeBSD that has gone out of support.
> If this problem can be reproduced on FreeBSD 13 or newer, please file a new bug
> so our triage processes get it on our radar.

I just crashed a Pi3 running
FreeBSD 14.0-RELEASE-p4 #0 releng/14.0-n265400-4edf3b80733e: Wed Dec 27 20:21:26 PST 2023
    bob@pelorus:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
by plugging in  a microSD to USB adapter with an old Rasbian Buster microSD card
installed.

The machine rebooted immediately, from the newly-inserted Buster installation.

Plugging in an FT232 usb-serial adapter was followed by:
 

FreeBSD/arm64 (pelorus.zefox.org) (ttyu0)

login: ugen1.4: <GenesysLogic USB2.1 Hub> at usbus1 (disconnected)
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 27 e0 b0 28 00 00 18 00 
uhub2: at uhub1, port 2, addr 4 (disconnected)
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain
ugen1.5: <JMicron SABRENT> at usbus1 (disconnected)
(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 27 e0 b0 28 00 00 18 00 
umass0: at uhub2, port 2, addr 5 (disconnected)
(da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <SABRENT  1214>  s/n 000000000000A detached
g_vfs_done(): da0p2 converting all errors to ENXIO
g_vfs_done():da0p2[WRITE(offset=342274080768, length=12288)]error = 6 supressing further ENXIO
panic: UFS: root fs would be forcibly unmounted
cpuid = 0
time = 1705223363
KDB: stack backtrace:
#0 0xffff00000050d52c at kdb_backtrace+0x58
#1 0xffff0000004b9044 at vpanic+0x19c
#2 0xffff0000004b8ea4 at panic+0x44
#3 0xffff0000007fd290 at ffs_fsfail_cleanup+0x178
#4 0xffff0000007d1748 at ffs_update+0x300
#5 0xffff00000080534c at ffs_syncvnode+0x62c
#6 0xffff000000803ce4 at ffs_fsync+0x28
#7 0xffff0000005cdd84 at kern_fsync+0x1b0
#8 0xffff000000896628 at do_el0_sync+0x5b0
#9 0xffff000000874110 at handle_el0_sync+0x44
Uptime: 6m28s
Resetting system ... 

It's stuck there. Pulling the plug brought it back up.

Prior to those failures, connecting a usb hard drive 
similar to the boot drive caused no problem,
just a console message announcing its presence.
Admittedly, I didn't wait very long before the
next experiment. 

All three tests were done via a powered usb hub.

Do these count as fair tests?

I'll add that even Pi4 RasPiOS isn't immune to such mischief.
Plugging in the same usb-microSD adapter with a card inserted
stops the mouse and keyboard working, with power cycling
the easiest recovery. Plugging in the adapter without a card
and then inserting the card allows normal recognition.
Haven't tried that with FreeBSD recently, it used to work
also. The FT232 also crashed RasPiOS, disabling keyboard
and mouse. The RasPiOS experiments didn't use a powerd
hub, but neither device draws much power. 

USB still seems a work in progress.

Thanks for reading, please indicate if a bug is warranted. 

bob prohaska