Solution Suggestion: USB Attached SCSI support (rasbian)

[keverik]

Dear raspberry linux kernel maintainers.

My suggestion is to enable the next kernel module for better support of USB to SATA converters:
Device drivers/USB support/USB Attached SCSI

This driver is in the debian linux distribution used for a long time, it just needs to be enabled and compiled.

Here is my story:
I had brought a new EWENT USB3.1 to 2.5" SATA controller to replace my old faulty converter.
It is reported by lsusb as a "ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge".

When the USB to SATA controller with SSD is connected to my debian linux is was working. (from at least kernel 4.9 on.)
This is the working logging:

[  812.557877] usb 1-5: New USB device found, idVendor=152d, idProduct=0567, bcdDevice= 1.17
[  812.557885] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  812.557889] usb 1-5: Product: USB 3.0 Device
[  812.557892] usb 1-5: Manufacturer: USB 3.0 Device
[  812.557895] usb 1-5: SerialNumber: 000000009DB8
[  812.585319] scsi host9: uas
[  812.586170] scsi 9:0:0:0: Direct-Access     KINGSTON  SA400S37240G    0117 PQ: 0 ANSI: 6
[  812.587239] sd 9:0:0:0: Attached scsi generic sg1 type 0
[  812.587772] sd 9:0:0:0: [sdb] 468862128 512-byte logical blocks: (240 GB/224 GiB)
[  812.587776] sd 9:0:0:0: [sdb] 4096-byte physical blocks
[  812.587953] sd 9:0:0:0: [sdb] Write Protect is off
[  812.587956] sd 9:0:0:0: [sdb] Mode Sense: **53** 00 10 08
[  812.588274] sd 9:0:0:0: [sdb] **Disabling FUA**
[  812.588278] sd 9:0:0:0: [sdb] Write cache: enabled, read cache: enabled, **doesn't support DPO or FUA**
[  812.590228]  sdb: sdb1
[  812.592304] sd 9:0:0:0: [sdb] Attached SCSI disk

When the USB to SATA controller with SSD is connected to my RBP is was working read only only. It turned out to be handled wrong by the scsi device driver. This is the logging:

[ 9518.368761] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
[ 9518.570829] usb 1-1.4: New USB device found, idVendor=152d, idProduct=0567
[ 9518.570852] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9518.570863] usb 1-1.4: Product: USB 3.0 Device
[ 9518.570873] usb 1-1.4: Manufacturer: USB 3.0 Device
[ 9518.570883] usb 1-1.4: SerialNumber: 000000009DB8
[ 9518.577361] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[ 9518.599440] scsi host0: usb-storage 1-1.4:1.0
[ 9519.680015] scsi 0:0:0:0: Direct-Access     KINGSTON  SA400S37240G    0117 PQ: 0 ANSI: 6
[ 9519.682022] sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
[ 9519.682896] sd 0:0:0:0: [sda] Write Protect is off
[ 9519.682922] sd 0:0:0:0: [sda] Mode Sense: **47** 00 10 08
[ 9519.683886] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, **supports DPO and FUA**
[ 9519.688264]  sda: sda1
[ 9519.710052] sd 0:0:0:0: [sda] Attached SCSI disk
[ 9519.786687] sd 0:0:0:0: Attached scsi generic sg0 type 0

Then when mounting...

[ 9670.601297] EXT4-fs (sda1): warning: mounting fs with errors, running e2fsck is recommended
[ 9670.602717] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 9670.602746] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x5 [current] 
[ 9670.602763] sd 0:0:0:0: [sda] tag#0 ASC=0x24 ASCQ=0x0 
[ 9670.602786] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x2a 2a 08 00 00 08 00 00 00 08 00
[ 9670.602801] print_req_error: critical target error, dev sda, sector 2048
[ 9670.602818] Buffer I/O error on dev sda1, logical block 0, lost sync page write
[ 9670.676313] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

And more of these..

A lot of concerns about these kind of errors are blamed to the power usage of the converters on internet. So (as a hardware engineer) I have measured to voltage at the USB port but no drop could be found. Also a USB hub did not give a effect.

It turned out that the "Disabling FUA" (in the working situation at my PC) is caused by setting "sdp->broken_fua" in the scsi disk driver. This disabling of FUA, enables the usage of the converter. Therefore this converter is listed in the drivers/usb/storage/unusual_devs.h file.

Unfortunately, this list of unusual devices is not used in the default kernel for (at least) the Raspbian distribution. Therefore my device (at likely more types) could be supported when this list is used.
I found that this list is enabled when then the USB Attached SCSI module is set on.

So I rebuild the kernel 4.14.93-v7+ with the "USB Attached SCSI" as module. And now my USB to SATA converter works Great! (kernel build instructions used from https://www.raspberrypi.org/documentation/linux/kernel/building.md with a make menuconfig)

I hope others can share in this good result.

[pelwell]

CONFIG_USB_UAS=m results in a 29kB module being built, which doesn't sound unreasonable. Are you happy for me to add it to the standard defconfigs, @popcornmix?

[popcornmix]

Yes

[pelwell]

Pushed to 4.14, 4.19, 4.20 and 5.0 kernels.

[keverik]

Thanks! Do I have to post something on the raspbian site as well?

[pelwell]

No - the module will appear in all future firmware releases. rpi-update will be the first channel to receive it, probably in a few days, then the Raspbian raspberrypi-kernel package, then eventually a full Raspbian image.

[keverik]

OK Thanks for you information

[6by9]

This has just been referenced by LibreElec folk.

#875 was @P33M disabling UAS as it didn't work because dwc_otg didn't support SG transfers. Has that now been addressed? (Or possibly UAS no longer mandates sg?)

[6by9]

UAS does mandate sg
https://github.com/raspberrypi/linux/blob/rpi-4.14.y/drivers/usb/storage/uas-detect.h#L127
and dwc_otg doesn't support it
https://github.com/raspberrypi/linux/blob/rpi-4.14.y/drivers/usb/host/dwc_otg/dwc_otg_hcd_linux.c#L624

Still true in 4.19 too.

[pelwell]

Is there no per-controller mechanism to enable/disable UAS support?

[P33M]

The UAS module is probed by default for all devices not matching a VID:PID quirk and it bails out when it discovers that the controller doesn't support sg. USB mass-storage support is also required for all devices that support UAS, so the failure is benign.

I don't understand why the declarations of broken devices (many of which set quirks relevant to usb-storage) are hiding behind a CONFIG_UAS parameter - usb-storage exists independently of UAS.

[keverik]

I do not fully understand the issue. (Maybe the list of broken devices should be scanned at a different module?) But if I can help with my testcase, let me know.

[keverik]

Just to complete the story:
I have tested it with rpi-update. It is OK now (for this issue).

Linux version 4.14.94+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1193 Tue Jan 22 15:18:37 GMT 2019

sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 47 00 10 08
sd 0:0:0:0: [sda] Disabling FUA
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Thanks all!

[MichaIng]

Just as a clarification, the drivers/usb/storage/unusual_devs.h list is only loaded as part of the uas kernel module, hence it does not only need to be compiled but loaded as well, i.e. blacklisting it breaks the OP issues solution, right?

Would be actually awesome if there was a way to load the list a different way, as currently two additional kernel modules are loaded (sg+uas) and each attached USB drive throws two kernel warnings as the until-RPi4 default USB driver dwc_otg does not support scatter-gather, so it's still only the list that is practically of use, not any other functionality of the modules:

[   10.464266] usb 1-1.2: The driver for the USB controller dwc_otg_hcd does not support scatter-gather which is
[   10.464281] usb 1-1.2: required by the UAS driver. Please try an other USB controller if you wish to use UAS.

Now one could consider to manually or by default enable another USB driver via dtoverlay=dwc2 to enable UAS support. But I have no idea if/what the benefits are, and FIQ is not supported then, where I also have no idea of the practical downsides 😄. But on RPi4, dwc2 IS enabled by default and now we (DietPi) and RPi repos and forum receive regular reports about failing mounts and boots from USB drives because many drives (respectively drive firmware) do not support UAS and fail then. Either USB quirks for UAS blacklisting are required, where a list cannot be practically maintained within the RPi kernel, or the UAS module itself needs to be blacklisted, to prevent such issues.

So I'm trying to evaluate whether by default blacklisting the two modules and/or reverting RPi 4 to dwc_otg, or the other way round enabling dwc2 on all RPi modules to enable UAS (but by this cause potential USB mount/boot issues like on RPi4), would be beneficial over the current situation.