Linux: dwc_otg doesn't support scatter-gather transfers

[P33M]

Plugging in a device that uses the UAS transport results in:

[   31.347619] usb 1-1.2.7: new high-speed USB device number 6 using dwc_otg
[   31.489885] usb 1-1.2.7: New USB device found, idVendor=174c, idProduct=07d1
[   31.489908] usb 1-1.2.7: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[   31.489926] usb 1-1.2.7: Product: TS128GESD400K
[   31.489942] usb 1-1.2.7: Manufacturer: StoreJet
[   31.489959] usb 1-1.2.7: SerialNumber: 20141120B8501907308D
[   31.491781] usb 1-1.2.7: The driver for the USB controller dwc_otg_hcd does not support scatter-gather which is
[   31.491807] usb 1-1.2.7: required by the UAS driver. Please try an other USB controller if you wish to use UAS.
[   31.491826] usb-storage 1-1.2.7:1.0: USB Mass Storage device detected
[   31.493612] scsi host0: usb-storage 1-1.2.7:1.0
[   31.518486] usbcore: registered new interface driver uas

and the device falls back to using usb-storage.
bus->sg_tablesize is zero.

http://lxr.free-electrons.com/ident?i=uas_use_uas_driver

[P33M]

UAS is now disabled as of 5e3fb8358a4918c1c6c3ad0706da28c90ef7f737, as the module was loaded but never did anything - thus wasting memory. Devices are required to fall back to using the USB mass storage class (which should be implemented on all devices that are UAS-capable).

This can be re-enabled once the SG support is implemented in dwc_otg.

[Ruffio]

@P33M has your issue been resolved? If yes, then please close this issue.

[P33M]

SG transfer support will require quite a lot of rewrite in dwc_otg. Implementing this is contingent on it being a block for something else.

[JamesH65]

@p33m I presume there has been no change on this issue?

[Syonyk]

Posting to follow. I've run into the same issue.

Does anyone have the dwg_otc device datasheets that might be useful for implementing scatter-gather?

[MichaIng]

@P33M @Ruffio
Has something changed about this?

With the latest update to 4.14.98 I found the uas module being loaded:

2019-02-19 20:18:48 root@micha:/tmp# lsmod
Module                  Size  Used by
sg                     28672  0
uas                    24576  0
fixed                  16384  0

Shouldn't this be disabled then by default? dmesg still shows the scatter-gather warning.

SG transfer support will require quite a lot of rewrite in dwc_otg. Implementing this is contingent on it being a block for something else.

Does this mean currently when attaching an external drive via USB to the RPi, the sg (=scatter-gather?) module is not used as well, thus can be as well disabled?

EDIT

Just read: https://github.com/raspberrypi/linux/issues/2813
But I am not sure if I fully understood it. USB attached SCSI (UAS) support enabled in kernel, but the USB controller driver still doesn't support it. Does this make any sense then? Or is it device specific (I use RPi2)? Ah just see that I am not the only one who is confused but that enabling the UAS module enables support for some USB to SATA controllers in fact.

---

OOT: And as the last dynamic module would be fixed does someone know where it assures fixed voltage? I read that it's only about GPIO I2C and such, which I don't use. So could I unload (blacklist) it as well? I just didn't touch it so far, since if it affects CPU/core/USB voltage as well, of course it sounds important 😉.

[zofiel]

no news about this? thanks

[nkichukov]

Any chances we are getting scatter-gather implemented for dwc_otg_hcd sooner than later? That would be great!
Thanks!
-N

[JamesH65]

Seems unlikely to be sooner, we are quite busy on other stuff.

[Syonyk]

Is it possible to get the documents, via some path or another, required to implement such a thing?

There exist people who have experience in the kernel, writing drivers, as part of the Raspberry Pi user community. However, I've looked, and can't find the documents that would be needed to write a new USB driver for the Pi, or modify it to work with SG.

There are a few notes in here: https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

But they're not a complete description of the USB hardware, by any means.

If there's some documentation (or could be) of the actual limitations in the existing architecture of the driver that prevent scatter-gather (or emulation of), people could try to work towards a better driver.

[P33M]

The limitation is that there is a 1:1 mapping between a USB transfer and a single, contiguous DMA transfer in hardware. To implement scatter-gather, you'd have to rewrite significant chunks of the driver to split out a SG URB's individual transfer fragments into separate QTDs, then have another method of joining up all the completions once the hardware's done the sub-transfers.

This would a) require significant software engineering time and b) add a ton of overhead to an already bloat-heavy driver. In short, we've not got a case where SG is an absolute requirement therefore a driver rewrite is not going to happen.

UAS is now re-enabled because it adds a bunch of quirks for newer usb-storage devices. The module is loaded but as there's no SG support, UAS devices are accessed as mass-storage class devices.

[MichaIng]

Does dwc2 support sg > uas, hence via dtoverlay=dwc2?

[mirh]

Wasn't that added here?

[h3x4d3c1m4l]

Wasn't that added here?

I don't think so (at least in this particular patch), as it mentions gadget mode. This is the mode where the Raspberry Pi will act as a USB device itself.

Perhaps somewhat relevant, as some (like me) are looking for UAS support just to enable TRIM/discard. I figured out it's actually possible to enable TRIM support for some USB enclosures even when in BOT (non-UAS) mode. https://wiki.archlinux.org/index.php/Solid_state_drive#External_SSD_with_TRIM_support.

This won't get you UAS, but at least will get you TRIM/discard support for SSD's when the SATA-to-USB chip has the proper support implemented.

EDIT: above solution it not stable for me (Crucial M4 on UGreen with ASM chipset), it eventually spams I/O errors to the kernel log when discarding large areas

[h3x4d3c1m4l]

I just tested dwc2 as possible solution, but also no sg support there:

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

as of kernel Linux ubuntu 5.4.0-1025-raspi (official Ubuntu 20.04 kernel running the Pi 3B 1.2)

[crocket]

I don't need UAS. I want external SSD with TRIM support.

[MichaIng]

I just tested dwc2 as possible solution, but also no sg support there:

Strange, on RPi 4 it is, as UAS works on RPi 4 with dwc2 as default USB controller driver.

[crocket]

UAS works fine with USB 3.

[h3x4d3c1m4l]

I just tested dwc2 as possible solution, but also no sg support there:

Strange, on RPi 4 it is, as UAS works on RPi 4 with dwc2 as default USB controller driver.

The USB 2 ports of the RPi 4 do not use the dwc2 driver but these are connected to the XHCI controller of the RPi 4 (Source). The dwc2 driver seems to be needed for the USB-C port which can operate in both slave and host modes.

And as the VL805 and the XHCI driver support UAS, UAS will just work on the RPi 4.

[h3x4d3c1m4l]

I don't need UAS. I want external SSD with TRIM support.

I got this actually working yesterday. I did the steps found on the Arch Linux wiki, but it did not mention setting discard_max_bytes for the disk. Setting this to the correct value (and persisting it using an udev rule) has TRIM fully working for me on my Pi 3B without spamming I/O errors in the kernel log.

I followed the steps from this blog. Additionally the steps for persisting the discard_max_bytes setting can be found in the comments.

Hope this helps anyone that needs TRIM support for their SSD!