Results 1 to 8 of 8

Thread: Cannot disable uas

  1. #1

    Unhappy Cannot disable uas

    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. #2
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,381
    Blog Entries
    1

    Default Re: Cannot disable uas

    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. #3
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Cannot disable uas

    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. #4

    Thumbs down uas is a disaster

    Quote Originally Posted by deano_ferrari View Post
    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.

    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. #5

    Default Re: Cannot disable uas

    Quote Originally Posted by robin_listas View Post
    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.
    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. #6
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Cannot disable uas

    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. #7
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,381
    Blog Entries
    1

    Default Re: uas is a disaster

    Quote Originally Posted by ZStefan View Post

    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.
    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. #8

    Unhappy Warning is needed.

    Quote Originally Posted by wolfi323 View Post
    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.
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •