Launch a custom script at reboot before system recognises USB devices

    • OMV 4.x
    • Resolved

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Launch a custom script at reboot before system recognises USB devices

      I own an external USB 3.0 enclosure with the chip Asmedia ASM1051E that reports lots of error to syslogs:

      Source Code

      1. sd 8:0:0:0: [sdi] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD
      2. sd 8:0:0:0: [sdi] tag#1 CDB: Write(10) 2a 00 48 c0 81 00 00 00 01 00
      3. scsi host8: uas_eh_device_reset_handler start
      4. usb 2-1: reset SuperSpeed USB device number 2 using xhci_hcd
      5. scsi host8: uas_eh_device_reset_handler success
      6. usb 2-1: Disable of device-initiated U1 failed.
      7. usb 2-1: Disable of device-initiated U2 failed.
      8. sd 8:0:0:0: [sdi] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
      9. sd 8:0:0:0: [sdi] tag#0 CDB: ATA command pass through(16) 85 09 0e 00 00 00 01 00 11 00 00 00 00 00 2f 00
      10. xhci_hcd 0000:00:14.0: ERROR Unknown event condition 199 for slot 4 ep 3 , HC probably busted


      I have done some research about it, and I found that the chip itself has broken support under UAS mode and that the best option is to run it as regular USB storage mode.

      Blacklisting the vendor_id:product_id with the following command resolves the incompatibility problem:


      Source Code

      1. echo "174c:55aa:u" >/sys/module/usb_storage/parameters/quirks

      But it has to be done at each reboot, before the system recognises the external USB enclosure.

      I have tried to do a scheduled job at reboot executed with root but it gets launched after the system detects the external USB enclosure and therefore it uses UAS for it. So I have to turn the external drive off, relaunch the script and turn it on again each time the system reboots.

      Is there any way to execute a custom script at a "lower level", before the system recognises the USB devices attached to it? Maybe at /etc/init.d/ or /etc/rc.local?

      Thanks in advance.
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||
    • jfromeo wrote:

      Is there any way to execute a custom script at a "lower level", before the system recognises the USB devices attached to it? Maybe at /etc/init.d/ or /etc/rc.local?
      Why not solving your problem instead. Quick web search for 'debian blacklist uas' ends up here: unix.stackexchange.com/questio…n-usb3-hdd-uas-i-o-errors (if you run on x86 then follow the last answer and not how I prepared it with Armbian)

      The post was edited 1 time, last by tkaiser ().

    • tkaiser wrote:

      jfromeo wrote:

      Is there any way to execute a custom script at a "lower level", before the system recognises the USB devices attached to it? Maybe at /etc/init.d/ or /etc/rc.local?
      Why not solving your problem instead. Quick web search for 'debian blacklist uas' ends up here: unix.stackexchange.com/questio…n-usb3-hdd-uas-i-o-errors (if you run on x86 then follow the last answer and not how I prepared it with Armbian)
      I tried the latest solution but it does not prevent the UAS from being loaded:

      Source Code

      1. echo "options usb-storage quirks=174c:55aa:u" >> /etc/modprobe.d/usb-storage-quirks.conf
      2. update-initramfs -u
      It generates a usb-storage-quirks.conf in modprobe correctly, but when doing a lsusb -t:

      Source Code

      1. /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
      2. |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
      3. |__ Port 9: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
      4. /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
      5. |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
      6. |__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
      The Bus 02-Port 1-Dev 3 is the external enclosure (which should be "Driver=usb-storage"). The Bus 02-Port 9-Dev 2 is the cache SSD.

      With the UAS driver it gests lots of device resets, SMART warnings and I/O errors in syslog.

      What I need to do is prevent the system from loading UAS for that vendor ID (blacklist definitely, I would prefer not to disable UAS for other devices as my cache SSD uses it correctly) since the boot sequence, as if it gets loaded, no matter what I do it does not change the driver until i turn it off/on or unplug/plug the cable.
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||
    • tkaiser wrote:


      jfromeo wrote:

      It generates a usb-storage-quirks.conf in modprobe correctly, but when doing a lsusb -t:
      Just to be sure: Did you reboot in between?
      Oh right, after a reboot it loads it as usb-storage, thank you a lot.

      The weird part is that it seems to have disabled completely uas because my cache SSD has changed from uas to usb-storage too. I have rechecked the vendor_id and product_id chain for my external enclosure in the quirks file.

      I prefer not having issues with the external drive to have a minimal boost on the cache disk so I will leave it as is now.

      Source Code

      1. /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
      2. |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
      3. |__ Port 9: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
      4. /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
      5. |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
      6. |__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
      Thank you again!
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||
    • tkaiser wrote:

      jfromeo wrote:

      The weird part is that it seems to have disabled completely uas
      Hmm... unlikely but without knowing the contents of /etc/modprobe.d/usb-storage-quirks.conf and output of lsusb I can't tell anything... you might also watch dmesg output for informative messages...
      Here they go:
      cat /etc/modprobe.d/usb-storage-quirks.conf

      Source Code

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

      Source Code

      1. Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge
      2. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
      3. Bus 001 Device 003: ID 8564:1000 Transcend Information, Inc. JetFlash
      4. Bus 001 Device 002: ID 051d:0003 American Power Conversion UPS
      5. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
      lsusb -t (without the external hdd attached)

      Source Code

      1. /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
      2. |__ Port 9: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
      3. /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
      4. |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
      5. |__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
      lsusb -t (with the external hdd attached)

      Source Code

      1. /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
      2. |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
      3. |__ Port 9: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
      4. /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
      5. |__ Port 4: Dev 2, If 0, Class=Human Interface Device, Driver=usbfs, 12M
      6. |__ Port 6: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
      dmesg (since the moment I attached the external drive)

      Brainfuck Source Code

      1. [ 420.954932] usb 2-1: new SuperSpeed USB device number 3 using xhci_hcd
      2. [ 420.975584] usb 2-1: New USB device found, idVendor=174c, idProduct=55aa
      3. [ 420.975590] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
      4. [ 420.975594] usb 2-1: Product: -TS07
      5. [ 420.975598] usb 2-1: Manufacturer: SST
      6. [ 420.975601] usb 2-1: SerialNumber: AA00000000007E
      7. [ 420.976442] usb 2-1: UAS is blacklisted for this device, using usb-storage instead
      8. [ 420.976447] usb-storage 2-1:1.0: USB Mass Storage device detected
      9. [ 420.976691] usb-storage 2-1:1.0: Quirks match for vid 174c pid 55aa: c00000
      10. [ 420.976749] scsi host10: usb-storage 2-1:1.0
      11. [ 421.979479] scsi 10:0:0:0: Direct-Access SST -TS07 0 PQ: 0 ANSI: 6
      12. [ 421.979857] sd 10:0:0:0: Attached scsi generic sg10 type 0
      13. [ 421.980753] sd 10:0:0:0: [sdk] Spinning up disk...
      14. [ 423.002829] .................ready
      15. [ 440.517935] sd 10:0:0:0: [sdk] 2441609216 4096-byte logical blocks: (10.0 TB/9.10 TiB)
      16. [ 440.518494] sd 10:0:0:0: [sdk] Write Protect is off
      17. [ 440.518499] sd 10:0:0:0: [sdk] Mode Sense: 43 00 00 00
      18. [ 440.518714] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
      19. [ 440.565532] sdk: sdk1
      20. [ 440.566759] sd 10:0:0:0: [sdk] Attached SCSI disk
      Display All
      Thanks again.

      I am ok with this, I do not think I will miss any real performance between uas and usb-storage driver on the cache drive.
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||
    • jfromeo wrote:

      I do not think I will miss any real performance between uas and usb-storage driver on the cache drive
      UAS or the old and anachronistic mass storage mode can make a huge difference wrt random IO. And I was a bit unclear about what could be interesting before: it's not about the external disk but your cache SSD that seems to be missing on most outputs you posted directly above.

      Anyway: one problem with ASMedia's chipsets is that the vendor reused product IDs for different chips so proper detection gets tricky. Which kernel version are you running with (uname -a)?
    • tkaiser wrote:

      jfromeo wrote:

      I do not think I will miss any real performance between uas and usb-storage driver on the cache drive
      UAS or the old and anachronistic mass storage mode can make a huge difference wrt random IO. And I was a bit unclear about what could be interesting before: it's not about the external disk but your cache SSD that seems to be missing on most outputs you posted directly above.
      Anyway: one problem with ASMedia's chipsets is that the vendor reused product IDs for different chips so proper detection gets tricky. Which kernel version are you running with (uname -a)?
      uname -a

      Source Code

      1. Linux olmos13nas 4.16.0-0.bpo.2-amd64 #1 SMP Debian 4.16.12-1~bpo9+1 (2018-06-03) x86_64 GNU/Linux
      || omv 4.0.14 | kernel 4.9.0 | omvextrasorg 4.1.0 ||