Arch Linux

dmartins

Member

Registered: 2006-09-23

Posts: 360

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Thanks everyone. This worked for me too. I was going down the wrong path of playing with transparent hugepage settings before finding this thread.

I have the same drive as Larsson: 0bc2:3312

tmoorman

Member

Registered: 2012-08-07

Posts: 22

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

This works for me as well.
Apparently I have the same hardware as rubenvb @ #24.
Or at least the controller is the same.  Mine is a Thermaltake BlacX 5G docking station, USB 3.0.
After mkinitcpio and reboot this is my dmesg after turning on the BlacX with my WD hard drive attached:

[   30.133712] usb 2-1: new SuperSpeed USB device number 2 using xhci_hcd
[   30.178389] usb-storage 2-1:1.0: USB Mass Storage device detected
[   30.178845] usb-storage 2-1:1.0: Quirks match for vid 174c pid 5106: 800000
[   30.178863] scsi14 : usb-storage 2-1:1.0
[   30.178939] usbcore: registered new interface driver usb-storage
[   30.180232] usbcore: registered new interface driver uas
[   31.182578] scsi 14:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6
[   41.439339] sd 14:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[   41.439944] sd 14:0:0:0: [sdd] Write Protect is off
[   41.439949] sd 14:0:0:0: [sdd] Mode Sense: 43 00 00 00
[   41.440603] sd 14:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   41.504983]  sdd: sdd1
[   41.506780] sd 14:0:0:0: [sdd] Attached SCSI disk
[   44.993835] EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)

Since my only usb 3.0 device is the BlacX this work around will suffice until the permanent fix.

Markus.N2

Member

From: Germany

Registered: 2013-08-22

Posts: 99

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

I have another question about the workaround ... just out of curiosity:
Why is it necessary to create a new initrd ?
I thought the initrd is only used in the first phase of the boot process until everything is prepared to mount the / filesystem. But the quirk is used when the system is already up and running - at least for mainboards that are not able to boot from a device connected to the USB3 port (like mine).

Da_Coynul

Member

From: United States of America

Registered: 2010-10-02

Posts: 85

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Markus,

For me, the quirk did not get picked up until I regenerated initrd. Maybe it was a coincidence...feel free to test!

Jonathan

I have another question about the workaround ... just out of curiosity:
Why is it necessary to create a new initrd ?
I thought the initrd is only used in the first phase of the boot process until everything is prepared to mount the / filesystem. But the quirk is used when the system is already up and running - at least for mainboards that are not able to boot from a device connected to the USB3 port (like mine).

ephemient

Member

Registered: 2014-07-30

Posts: 1

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

This worked for me on one machine, live (just had to unplug and re-plug the USB HDD):

rmmod uas usb-storage
modprobe usb-storage quirks=0bc2:ab21:u

And so did this, on another where usb-storage was still in use by other devices:

echo -n quirks=0bc2:ab21:u | sudo tee /sys/modules/usb_storage/params/quirks

Of course you still want to put it into /etc/modprobe.d and regenerate initrd so that it automatically applies on the next boot.

(This USB ID is for a Seagate Backup Plus Slim USB 3.0 Portable.  Whew, that's a long name.)

Last edited by ephemient (2014-07-30 05:59:49)

Markus.N2

Member

From: Germany

Registered: 2013-08-22

Posts: 99

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

In between, I have noticed that the file /etc/modprobe.d/ignore_uas.conf is included in the initd image. So it seems like the usb_storage and usb_uas modules are indeed loaded very early during booting. That's why creating a new initrd after adding or changing this file is necessary.

But I have another question:
Can I exclude this file for the lts kernel's initrd ?

I just booted the lts kernel for the first time since I added the quirk, and I noticed that it causes systemd-modules-load.service to fail. I think it is because the lts kernel does not know this quirk.

Last edited by Markus.N2 (2014-08-24 14:43:09)

lilydjwg

Member

Registered: 2010-06-20

Posts: 53

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

This worked for me on one machine, live (just had to unplug and re-plug the USB HDD):

rmmod uas usb-storage
modprobe usb-storage quirks=0bc2:ab21:u

And so did this, on another where usb-storage was still in use by other devices:

echo -n quirks=0bc2:ab21:u | sudo tee /sys/modules/usb_storage/params/quirks

Of course you still want to put it into /etc/modprobe.d and regenerate initrd so that it automatically applies on the next boot.

(This USB ID is for a Seagate Backup Plus Slim USB 3.0 Portable.  Whew, that's a long name.)

I have this very HDD (same ids though the name seems to differ a bit) and this option helps on my machine. Thanks :-)

hansdegoede

Member

Registered: 2014-09-12

Posts: 16

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Hi All,

I'm the upstream uas driver maintainer. I'm sorry to hear that the new uas code is causing trouble for some of you. I'm afraid that the only way to solve this, sort of disabling uas all together, which is a bad idea as it really is the future of usb storage, is to work through all the issues you are having one by one.

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, as well as improved logging so we can easier figure out the cause of errors.

I would like to ask you all to test a standalone version of the new uas driver with the devices you've been having trouble with before, and report the results to me. Testing instructions:

1) Remove any usb-storage.quirks= setting from the kernel commandline, and remove any /etc/modprobe.conf* files doing the same, boot your machine without the uas device attached.

2) Make sure your machine is set up for building kernel modules, usually this means installing kernel-devel and gcc packages, see your distributions documentation for more info

3) Download all files from here:
https://fedorapeople.org/~jwrdegoede/uas/
And put them all in a single directory, named e.g. uas

4) Start a terminal, cd into the uas directory

5) Run the following commands:
make
sudo rmmod uas
sudo insmod ./uas.ko

6) Connect your uas device

7) Wait for the disk to show up (wait circa 1 minute max), then do:

dmesg > dmesg.log
lsusb -v > lsusb.log
lspci -nn > lspci.log

8) Test the uas disk

Once done please send me a mail at hdegoede@redhat.com , in this mail please:

1) Describe how the disk worked, did it show up in a reasonable time, and did it work?

2) Attach dmesg.log, lsusb.log and lspci.log

One last note, a lot of people in this forum thread seem to be using seagate disk enclosures, at least one problem with (some?) seagate enclosures has been identified and fixed already. If you have a seagate enclosure, and this new version does not work out of the box for you, please try editing unusual_uas.h and changing the product-id of the one seagate entry already there from 0x2312 to the product-id of your enclosure, then redo:

make
sudo rmmod uas
sudo insmod uas.ko

Replug your device,  and let me know if that helps.

Thanks & Regards,

Hans

hansdegoede

Member

Registered: 2014-09-12

Posts: 16

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

p.s.

If you know which chipset your device is using, that may be of great help. So if you know this, or if you're willing to open your enclosure and take a look at the brand + number scribbled on the IC with a magnifying glass, then please include that info in your mail. Please do not guess based on usb-id, I can do that myself Having the actual info from the IC otoh can be quite useful.

Thanks,

Hans

hansdegoede

Member

Registered: 2014-09-12

Posts: 16

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Hi All,

Quick update on this, Matse has contacted me by email, and indeed the Seagate 0bc2:3312 disk needs the same quirk as the seagate enclosure I already knew about.

I've uploaded an updated unusual_uas.h to:

https://fedorapeople.org/~jwrdegoede/uas/

So when using the version of the uas driver there, things should now work for owners of a 0bc2:3312 disk without needing to add a quirk to disable uas, see my previous post for build instructions.

Regards,

Hans

rhester72

Member

Registered: 2013-05-02

Posts: 7

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Quick update on this, Matse has contacted me by email, and indeed the Seagate 0bc2:3312 disk needs the same quirk as the seagate enclosure I already knew about.

I've uploaded an updated unusual_uas.h to:

https://fedorapeople.org/~jwrdegoede/uas/

So when using the version of the uas driver there, things should now work for owners of a 0bc2:3312 disk without needing to add a quirk to disable uas, see my previous post for build instructions.

Another one:

0x0bc2:0xab20 (Seagate Backup+ BK, 2TB)

Rodney

Last edited by rhester72 (2014-09-17 02:21:51)

SkyBon

Member

Registered: 2009-11-25

Posts: 6

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Quick update on this, Matse has contacted me by email, and indeed the Seagate 0bc2:3312 disk needs the same quirk as the seagate enclosure I already knew about.

I've uploaded an updated unusual_uas.h to:

https://fedorapeople.org/~jwrdegoede/uas/

So when using the version of the uas driver there, things should now work for owners of a 0bc2:3312 disk without needing to add a quirk to disable uas, see my previous post for build instructions.

Another one:

0x0bc2:0xab20 (Seagate Backup+ BK, 2TB)

Rodney

0bc2:ab21 too.

hansdegoede

Member

Registered: 2014-09-12

Posts: 16

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Hi,

Another one:

0x0bc2:0xab20 (Seagate Backup+ BK, 2TB)

Rodney

0bc2:ab21 too.

Thanks, I've send kernel patches adding both of them to the offical quirk table upstream.

Keep them coming

Regards,

Hans

nbi

Member

Registered: 2014-11-05

Posts: 3

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

I cannot get this to work, i.e. I cannot disable UAS in the 3.16.3 kernel. I have not yet brute forced the source code as I'm hoping that's a last resort. "quirks" does nothing. Whenever I power up my Plugable USB3-SATA-UASP1 docking station I can see UAS enabled in the kernel log. I've even updated the NEC renesas firmware of my ASUS U3S6 controller card to no effect.

So what can be done to disable UAS if quirks doesn't work? Please don't suggest blacklisting the modules because I don't use any for this - all the usb code is built into the kernel.

Thought I saw a discussion between Hans & Greg about usbcore.nouas kernel cmdline option. I'll try it, but feel free to tell me if it was implemented or not. Thanks.

hansdegoede

Member

Registered: 2014-09-12

Posts: 16

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

I cannot get this to work, i.e. I cannot disable UAS in the 3.16.3 kernel. I have not yet brute forced the source code as I'm hoping that's a last resort. "quirks" does nothing. Whenever I power up my Plugable USB3-SATA-UASP1 docking station I can see UAS enabled in the kernel log. I've even updated the NEC renesas firmware of my ASUS U3S6 controller card to no effect.

So what can be done to disable UAS if quirks doesn't work? Please don't suggest blacklisting the modules because I don't use any for this - all the usb code is built into the kernel.

Thought I saw a discussion between Hans & Greg about usbcore.nouas kernel cmdline option. I'll try it, but feel free to tell me if it was implemented or not. Thanks.

usbcore.nouas was never implemented, but you should be able to add: usb-storage.quirks=vid:pid:u on the kernel commandline to disable uas, e.g.:

usb-storage.quirks=174c:55aa:u

Please check the usb ids match with your device, also after booting please do "cat /proc/cmdline" and ensure you've properly added the parameter to the kernel commandline.

Note that this is just a workaround. I'm a bit amazed that things do not work for you with the USB3-SATA-UASP1, as that is the device both I and Sarah Sharp (the former XHCI kernel maintainer) have used to develop and test the uas driver ...  What happens when you try to use it in uas  mode?

Can you please try building the standalone version of the module following the testing instruction I've posted earlier in this thread ? That module at a minimum should stop uas from crashing your system, note only plugin the device after the rmmod uas; modprobe usb-storage; insmod ./uas.ko sequence. Then after plugging it in, do: "dmesg > dmesg.log" and then send me a mail with dmesg.log attached.

Regards,

Hans

nbi

Member

Registered: 2014-11-05

Posts: 3

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

I cannot get this to work, i.e. I cannot disable UAS in the 3.16.3 kernel. I have not yet brute forced the source code as I'm hoping that's a last resort. "quirks" does nothing. Whenever I power up my Plugable USB3-SATA-UASP1 docking station I can see UAS enabled in the kernel log. I've even updated the NEC renesas firmware of my ASUS U3S6 controller card to no effect.

So what can be done to disable UAS if quirks doesn't work? Please don't suggest blacklisting the modules because I don't use any for this - all the usb code is built into the kernel.

Thought I saw a discussion between Hans & Greg about usbcore.nouas kernel cmdline option. I'll try it, but feel free to tell me if it was implemented or not. Thanks.

usbcore.nouas was never implemented, but you should be able to add: usb-storage.quirks=vid:pid:u on the kernel commandline to disable uas, e.g.:

usb-storage.quirks=174c:55aa:u

That works (without errors)! Thank you. I was trying to shut down UAS after booting by using an echo, but that doesn't work.

I'm curious why the external endpoint (USB3-SATA-UASP1) rather than the internal (U3S6) is specified for the quirks. Maybe if one end says "I don't have UAS" it simply isn't negotiated?

Please check the usb ids match with your device, also after booting please do "cat /proc/cmdline" and ensure you've properly added the parameter to the kernel commandline.

Note that this is just a workaround. I'm a bit amazed that things do not work for you with the USB3-SATA-UASP1, as that is the device both I and Sarah Sharp (the former XHCI kernel maintainer) have used to develop and test the uas driver ...  What happens when you try to use it in uas  mode?

When I try to write to the drive a repeating cycle of errors and resets takes place that usually ends with a drive crash:

usb 10-2: new SuperSpeed USB device number 10 using xhci_hcd
scsi14 : uas
mtp-probe: checking bus 10, device 10: "/sys/devices/pci0000:00/0000:00:09.0/0000:04:00.0/0000:05:01.0/0000:06:00.0/usb10/10-2"
mtp-probe: bus: 10, device: 10 was not an MTP device
scsi 14:0:0:0: Direct-Access     WDC WD64 00AAKS-65A7B0    0    PQ: 0 ANSI: 6
sd 14:0:0:0: Attached scsi generic sg5 type 0
1250263728 512-byte logical blocks: (640 GB/596 GiB)
Write Protect is off
Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdd: sdd1
Attached SCSI disk
EXT4-fs (sdd1): mounted filesystem with ordered data mode. Opts: (null)
uas_eh_abort_handler ffff8802c81c8600 tag 4, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK timed out
uas_eh_abort_handler ffff8802c81c8780 tag 5, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9680 tag 6, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c8900 tag 7, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9380 tag 8, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9500 tag 9, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9c80 tag 10, inflight: CMD
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9200 tag 0, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c8300 tag 11, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9e00 tag 1, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c8000 tag 2, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
uas_eh_abort_handler ffff8802c81c9800 tag 3, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
sd 14:0:0:0: uas_eh_device_reset_handler
scsi host14: uas_eh_task_mgmt: LOGICAL UNIT RESET: error already running a task
scsi host14: uas_eh_bus_reset_handler start
uas_data_cmplt ffff8802c81c9800 tag 3, inflight: CMD abort
uas_data_cmplt ffff8802c81c8000 tag 2, inflight: CMD abort
uas_data_cmplt ffff8802c81c9e00 tag 1, inflight: CMD abort
uas_data_cmplt ffff8802c81c8300 tag 11, inflight: CMD abort
uas_data_cmplt ffff8802c81c9200 tag 0, inflight: CMD abort
uas_zap_dead ffff8802c81c8600 tag 4, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c8780 tag 5, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9680 tag 6, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c8900 tag 7, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9380 tag 8, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9500 tag 9, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9c80 tag 10, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9200 tag 0, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c8300 tag 11, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9e00 tag 1, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c8000 tag 2, inflight: CMD abort
abort completed
uas_zap_dead ffff8802c81c9800 tag 3, inflight: CMD abort
abort completed
usb 10-2: reset SuperSpeed USB device number 10 using xhci_hcd
xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88032c8c6400
xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88032c8c6448
xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88032c8c6490
xhci_hcd 0000:06:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88032c8c64d8
scsi host14: uas_eh_bus_reset_handler success
uas_eh_abort_handler ffff880081b33980 tag 0, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK timed out
uas_eh_abort_handler ffff880081b33380 tag 12, inflight: CMD OUT
scsi host14: uas_eh_task_mgmt: ABORT TASK: error already running a task
sd 14:0:0:0: uas_eh_device_reset_handler
scsi host14: uas_eh_task_mgmt: LOGICAL UNIT RESET: error already running a task
scsi host14: uas_eh_bus_reset_handler start
uas_data_cmplt ffff880081b33380 tag 12, inflight: CMD abort
uas_data_cmplt ffff880081b33980 tag 0, inflight: CMD abort
uas_zap_dead ffff880081b33980 tag 0, inflight: CMD abort
abort completed
uas_zap_dead ffff880081b33380 tag 12, inflight: CMD abort
abort completed
.
.

Now with UAS disabled the errors are all gone, but the transfer rate is as slow as molasses flowing uphill on a cold winter day.
At least we've established that UAS is broken in 3.16.3.

Standalone modules are difficult for me because I use mostly monolithic kernels without an initrd. Per another posters comments it seems an initrd is required which requires a research effort because I can't arbitrarily make some modules standalone whereas others are built into the kernel. I tried making UAS standalone before and the kernel failed to boot and it's not obvious why.

Let me know if the info I provided helps. I'm willing to spend more time on this, but there are limits. BTW, I opened a trouble ticket with Plugable. No response yet.

UPDATE: Plugable has just informed me that UAS was broken in kernels 3.15 & 3.16 and that 3.17 has solved their UAS issues. So I will try that right away.

Can you please try building the standalone version of the module following the testing instruction I've posted earlier in this thread ? That module at a minimum should stop uas from crashing your system, note only plugin the device after the rmmod uas; modprobe usb-storage; insmod ./uas.ko sequence. Then after plugging it in, do: "dmesg > dmesg.log" and then send me a mail with dmesg.log attached.

Regards,

Hans

Last edited by nbi (2014-11-06 20:45:50)

nbi

Member

Registered: 2014-11-05

Posts: 3

Re: uas problem in linux 3.15.1, need advice on the problem [SOLVED]

Plugable apparently was right. I just tested with the 3.17 kernel and the errors are gone and I see this in the kernel log:

usbcore: registered new interface driver uas

So this seems to be the fix. I'm not convinced UAS is making any positive difference in the performance, but at least it isn't getting in the way.

Regarding USB3 vs USB2 the improvement is a factor of 3. I was expecting a much greater improvement. More testing and research may be needed.