Cannot disable uas

English Hardware
#1

On a laptop running opensuse 13.2, the USB 3.0 port is causing trouble.

One explanation is defective uas module. uas is known to be broken since several years. It is likely written by Hans de Goede from Red Hat, Matthew Wilcox from Intel and Sarah Sharp from Intel.

Various attempts have been made to correct the module for several Linux kernels, but evidently they were not very successful.

I notice that when I plug in a USB 3.0 memory stick into USB 3.0 port, the USB 2.0 mouse becomes unresponsive after a few seconds when the memory stick gets recognized. This is the time when the uas module is loaded, as lsmod shows. Generally, the more the activity on USB 3.0 port, the less responsive the mouse is.

I tried to disable the loading in three ways, but it is still being loaded (I cannot remember a proverb about undying evil):

  • by creating a custom file blacklist.conf in /etc/modprobe.d and blacklisting the module there
  • by adding a blacklist uas line in 50-blacklist.conf
  • by adding brokenmodules=uas to kernel’s boot parameters.

In Windows on the same computer, the USB 3.0 port is working correctly.

Is there a way to block the uas module from being loading, or it has to be loaded?

#2

I wonder if the workaround described in the following thread (post #12) might be helpful here…

https://bbs.archlinux.org/viewtopic.php?id=183190

It essentially involves configuring the usb-storage module to ignore the UAS capability of the device.

#3

On 2015-07-27 11:46, ZStefan wrote:
> I tried to disable the loading in three ways, but it is still being
> loaded (I cannot remember a proverb about undying evil):

Blacklisting does not impede intentional (explicit) loading by
something. To absolutely block a module from loading you have to remove
it from the /lib/modules/something directory.

–
Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 “Bottle” (Minas Tirith))

#4

I have tried several things besides removing the module from /lib/modules/something directory. I will try that also. Nothing I tried worked.

I tried kernel 4.1.3 - situation with USB memory stick became worse.

I tried adding various disablings per USB device’s vendor ID and product ID as suggested in the other forum - didn’t work.

The same memory stick works in another computer running the same OS. uas is loaded and runs without problems.

Hans de Goede spoke on the Arch Linux’s forum in 2014 and said:

*"I’ve been working on uas for the past 10 days in a row to try and fix most issues, there really are 2 different issues in play here:

*1) The uas error handling paths have some bugs causing oopses / hangs when things enter the error handling paths.

*I’ve mostly rewritten the error handling paths, and I believe they are robust now, so plugging in an uas drive should no longer completely hose your system.

*2) Some uas capable sata <-> usb bridges our not 100% up to spec (no suprise there) and choke on certain scsi commands, causing things to go into the error handlng paths triggering 1.

*The solution for 2. is to figure out which commands these devices choke on, and add quirks for them telling the scsi midlayer to not try those commands, this is where I need your help.

*As said I’ve been working on making the uas driver more resilient to errors"

*One of his approaches is to collect the defective USB devices’ numbers and add them to a blocking list which likely is a header file in kernel source. Most troubles are caused by Seagate’s external drives and enclosures.

There was another development about to start but didn’t: something like no_uas driver.

However, me must keep in mind that the USB devices connect to laptop and work in Windows. How do they handle error-over-error-over-error situation?

#5

Also, you should run “mkinitrd” after blacklisting or removing the module.
Otherwise it will still be in the initrd (without a blacklist), and might be loaded before the real root partition is mounted.

Btw, brokenmodules=xxx only works for the installer, not the installed system.

#6

On 2015-07-27 20:06, wolfi323 wrote:

> Also, you should run “mkinitrd” after blacklisting or removing the
> module.

oh, yes, I forgot.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

#7

Did you regenerate the initial ram disk with ‘mkinitrd’ after adding that entry?

I’ve seen a few bug reports where Hans de Geodeas has suggested this workaround as well as providing patches to inhibit UAS for various affected hardware.

However, me must keep in mind that the USB devices connect to laptop and work in Windows. How do they handle error-over-error-over-error situation?

Ah, well that’s a question for the developers. Windows code is proprietary so can’t easily be inspected, and secondly it is in the manufacturers interest to test their hardware for us in such environments. Linux doesn’t enjoy that luxury, so the job of providing the necessary support isn’t easy.

#8

I ran mkinitrd. There were about ten complaints saying that some modules could not be loaded. But the computer boots and runs normally.

I didn’t know that brokenmodules=xxx only works for the installer; thanks.

I cannot work on this computer any more. I am giving it back to owner, with a warning about USB3 ports and devices. Hopefully he does not use a bad combination of USB3 memory sticks, ports, mice, keyboards, USB3 hubs.

Perhaps when a driver or other software sees a known-to-be-defective piece of hardware, it shall warn the user. There are cryptic messages in /var/log/messages, but none says that certain vendor and product combinations don’t function on USB3 port. Meanwhile, the programmer knows it.