[SOLVED] How to 'enforce' usage of uas on external usb-device

mccurly · 2025-09-22 00:05:11

Hello everybody, (It's me, again… )

Well, this time I bring you something that I believe some will appreciate:

Through a certain degree of hardship, that is searching through the internet, reading and testing, I have found that some of my JMicron equipped USB external enclosures would allow for the UASP protocol while others would not. Strangely enough, most of them were 'identified' with the same VID:PID, which is: 512d:0578.

But oddly, some 'triggered' the uas module, while others would only trigger the older usb-storage one. And stubborn as I am, I tried to figure out why.

(I needed them to have support for the uas module, because otherwise, the usage of trimming capabilities of the enclosed SSD's would not happen.)

So, I think I have found what might be some path to unravel that possibility of trimming.

One word: 'Firmware'!

The 'working' (trimming wise) enclosures, had a different firmware from those that were not recognized as uas.

So to try to fix this situation, and since the tools to flash firmware onto these JMicron devices only comes in two 'flavors' (Arm equipped Odroid or 'good ol' M$ Windows) and given that I only had access to the latter, that was the chosen way to go.

Set up a VM with Windows, and backed up the original non-working firmware, as well the working one, and using an old SSD lying around, I performed some tests:

Flashing the 'good' firmware onto the 'bad' chip, resulted successfully.

That is, the external usb started to allow trimming.

Well its managing module became the 'uas' instead of the former 'usb-storage'.

What, then, brings me here?

Somehow, the question from the title is 'of the essence':

There seem to be systems that pass the usb-storage quirks merely by 'nailing' the VID:PID whenever this information gets available to them.

What this means is that, although the enclosure is prepared for uas module it will be blacklisted from those systems and only be allowed usb-storage (BOT) protocol module.

Therefore, the question:

Is there any 'expedite' way to 'whitelist'/'force' or any of the like, the given hardware to use the uas module instead of the usb-storage?

That I know, one can 'empty' the '/sys/module/usb_storage/parameters/quirks' file like so:

echo "" > /sys/module/usb_storage/parameters/quirks

And 'be good to go'...

But how does one do this at 'boot' time? (Automatically)

Thank you for your time and any information.

P.s.: (spoiler alert) I came here firsthand (at Arch Linux Forums) because the investigation that I did was carried out on an Arch Linux based machine. I think this is something that reaches out several (if not all) distros that share the Linux Kernel. This is a Linux way of doing things. Nevertheless, I must say that the unwanted behavior is happening in ProxMox. I will direct this question there, as well, shortly. If I am breaking the rules, please do bear with me. I am certain that I mean well. And I apologize if the result was otherwise.

Last edited by mccurly (2025-09-23 19:13:54)

mmy8x · 2025-09-22 07:13:51

You can't force uas on a device which doesn't support it.

Is this descriptor present on the "bad" samples (lsusb -v)?

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98 <-- this is UAS
      iInterface              0

mccurly · 2025-09-22 18:21:43

mmy8x wrote:

You can't force uas on a device which doesn't support it.

Is this descriptor present on the "bad" samples (lsusb -v)?

    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98 <-- this is UAS
      iInterface              0

Hi, mmy8x, what do you mean by "bad" samples?

Presently this is what is returned by the command (lsusb -v) from the given device that is 'flashed' with, aparently, a working firmware, that is recognized as uas capable driver:

Bus 002 Device 005: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s
Negotiated speed: SuperSpeed (5Gbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0         9
  idVendor           0x152d JMicron Technology Corp. / JMicron USA Technology Corp.
  idProduct          0x0578 JMS578 SATA 6Gb/s
  bcdDevice            5.08
  iManufacturer           1 JMicron
  iProduct                2 USB to ATA/ATAPI Bridge
  iSerial                 3 0123456789ABCDEF
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0079
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              896mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98  
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        Command pipe (0x01)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        MaxStreams             32
        Status pipe (0x02)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-in pipe (0x03)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               7
        MaxStreams             32
        Data-out pipe (0x04)

As you can see from the above 'code' box, that uas 'bInterfaceProtocol' is present.

Nevertheless, what does the quote:

mmy8x wrote:

bInterfaceProtocol 98 <-- this is UAS

(...) actually mean?

Does it mean that the enclosure is capable of UAS, or that it is 'bad' and, therefore should be using the older BOT protocol?

Does my question seem reasonable to you?

Besides, I think my post it is relevant to our Arch Community, because in Arch Linux, the module that is loaded is the expected one. That is, UAS, but unexpectedly (or not, someone please advise), the USB-STORAGE, for ProxMox. So there are definitely differences between the two systems (kernel wise, I am guessing).

Thank you for your time and reading!

mmy8x · 2025-09-23 08:05:31

mccurly wrote:

Hi, mmy8x, what do you mean by "bad" samples?
Presently this is what is returned by the command (lsusb -v) from the given device that is 'flashed' with, aparently, a working firmware, that is recognized as uas capable driver

By "bad" I mean devices which don't work with uas driver. If they don't have this descriptor it simply means that they don't support uas at all and there is nothing you can do, unless it's a matter of firmware upgrade.

If you see the descriptor but uas doesn't work then there is a problem.
But also, if it only ever happens on non-Arch distribution, it's somebody else's problem

mccurly · 2025-09-23 17:59:11

mmy8x wrote:

By "bad" I mean devices which don't work with uas driver. If they don't have this descriptor it simply means that they don't support uas at all and there is nothing you can do, unless it's a matter of firmware upgrade.
If you see the descriptor but uas doesn't work then there is a problem.
But also, if it only ever happens on non-Arch distribution, it's somebody else's problem

It happened with these devices on Arch as well.

The 'Arch' behavior, however is as expected. By this I mean, that it recognizes the firmware (at least I think so), and acts 'accordingly'. I mean it uses the 'uas' driver without further 'tweaking'. (Remember that I did a firmware update from inside a VM running on top of Arch host machine?) Before this 'firmware update' (upgrade?), neither ProxMox, nor Arch would 'behave'. That is why I came here and present this.

BTW. The tweaking (that is needed on ProxMox), is:

echo "" > /sys/module/usb_storage/parameters/quirks

I believe that maybe this has got to do with ProxMox kernel version. So I issued a help request there as well.

https://forum.proxmox.com/threads/how-t … ox.172556/

Thank you, again, for your reading and participation!

Xephon · 2025-09-23 18:33:42

Clearing quirks should be possible by adding usbcore.quirks= to the kernel command line
https://github.com/torvalds/linux/blob/ … 2-L6608C16

mccurly · 2025-09-23 19:13:09

Xephon wrote:

Clearing quirks should be possible by adding usbcore.quirks= to the kernel command line
https://github.com/torvalds/linux/blob/ … 2-L6608C16

Hi, thank you. I consulted that kernel parameters text file, but wasn't aware that to unset it I was allowed to blank it the way you have cleared out!

Amazing!

And It makes perfect sense! After all it should (and I believe it does) end up being the same as issuing that echo command on top of a running system.

And one last disclosure, which maybe could have avoided this plea for help:

I had (previously, I mean) before having found that the firmware is (or can be) of the utmost importance to allow for 'uas', had modprobe configured to apply quirks on the said devices. I overlooked (and this is the key to myself having wound up here), that I had to regenerate the 'initramfs' after having changed those usb-storage quirks module parameters.

Before they were like so:

options usb-storage quirks=152d:0578:u

After (now) they are (un)set like so:

#options usb-storage quirks=152d:0578:u

And I even changed the modprobe.d(ir) file name. Before:

/etc/modprobe.d/usb-storage-quirks.conf

After (now):

/etc/modprobe.d/usb-storage-quirks.conf.bk

All useless since I did not regenerate the initramfs...

Duh for myself!

I apologize, therefore!

I think now it is fixed!

Marking this as solved, then!

Thank you to all who partipated!

Arch Linux

#1 2025-09-22 00:05:11

[SOLVED] How to 'enforce' usage of uas on external usb-device

#2 2025-09-22 07:13:51

Re: [SOLVED] How to 'enforce' usage of uas on external usb-device

#3 2025-09-22 18:21:43

Re: [SOLVED] How to 'enforce' usage of uas on external usb-device

#4 2025-09-23 08:05:31

Re: [SOLVED] How to 'enforce' usage of uas on external usb-device

#5 2025-09-23 17:59:11

Re: [SOLVED] How to 'enforce' usage of uas on external usb-device

#6 2025-09-23 18:33:42

Re: [SOLVED] How to 'enforce' usage of uas on external usb-device

#7 2025-09-23 19:13:09

Re: [SOLVED] How to 'enforce' usage of uas on external usb-device

Board footer