oh wow... dk how sustainable this 'workaround' is, but from my sniffing around for the culprit, one of the suggested cause points out to something called uas
that the drives are using (via the USB-SATA cables).
These #JMicron tings are what's used by my drives on the Pi:
Bus 002 Device 002: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
Bus 001 Device 006: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
Bus 001 Device 005: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
They're using uas
drivers:
$ sudo dmesg | grep -i uas
[ 0.899109] usbcore: registered new interface driver uas
[ 1.430272] scsi host0: uas
[ 2.488903] scsi host2: uas
[ 2.741227] scsi host3: uas
and the thing that seems to fix it (i.e. no longer crashes the entire USB stack on the Pi), is adding the following option to /boot/firmware/cmdline.txt
:
usb-storage.quirks=xxxx:yyyy:u
xxxx:yyyy
being the actual ID reported for those USB bridge used by the drives (in my case, those JMicrons).
After a reboot, instead of using uas
, they're using
usb-storage
, and the USB crash no longer occurs when using
#OMV (scanning disks).
mikahomelab@pi-0:~ $ sudo dmesg | grep -i uas
[ 0.918739] usbcore: registered new interface driver uas
[ 1.439226] usb 2-1: UAS is ignored for this device, using usb-storage instead
[ 1.439267] usb 2-1: UAS is ignored for this device, using usb-storage instead
[ 2.510028] usb 1-1.1.1: UAS is ignored for this device, using usb-storage instead
[ 2.510066] usb 1-1.1.1: UAS is ignored for this device, using usb-storage instead
[ 2.766095] usb 1-1.1.4: UAS is ignored for this device, using usb-storage instead
[ 2.766132] usb 1-1.1.4: UAS is ignored for this device, using usb-storage instead
Not sure of the impact on this, but so far, I'm hoping it's usable.
🔗 (More Details on
uas
/
usb-storage
on the
#RaspberryPi)
https://forums.raspberrypi.com/viewtopic.php?t=245931