[Bug 276309] OS craching [sic] on USB connection

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 14 Jan 2024 02:45:54 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276309

            Bug ID: 276309
           Summary: OS craching [sic] on USB connection
           Product: Base System
           Version: 14.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm@FreeBSD.org
          Reporter: fbsd@www.zefox.net

This is in response to Warner's closure of bug 205166

The test host I used was a Pi3 booted from a usb mechanical hard drive
connected via a powered hub running
FreeBSD pelorus.zefox.org 14.0-RELEASE-p4 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

The first test was to connect a former boot disk similar to the
one the machine was currently running from. No problem, normal
device discovery chatter on the console.

Next experiment was to connect a usb-serial adapter with an old Raspian
microSD already plugged into it. Response was an immediate reboot,
from the Raspian microSD

Las experiment was to plug in an FTDI usb-serial adapter, resulting in 
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 ...had to pull the plug.


All three tests were done via the powered usb hub.

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 powered
hub, but neither device draws much power.

USB still seems a work in progress.

-- 
You are receiving this mail because:
You are the assignee for the bug.