External USB HDD powers off

[ChrisJC]

Hi All,
I have just updated to Mint 20 (64bit) Cinnamon. I also purchased a 3Tb external HDD (USB 3.0) to help me migrate all of my machines over to Mint 20.
They all appear to suffer from the same issue with the HDD, but I'll just focus on one machine (Dell laptop, Vostro of quite some vintage).

tl:dr - Plugging in the HDD is OK initially - enumerates on USB, appears in Nemo. dmesg output good. df output good. Power LED good. Can read / write to device. Then after 30 seconds, the power LED goes off, and then if I try to access the device, I get errors and dmesg shows some unhappiness.

lsusb:

Code: Select all

Bus 002 Device 004: ID 8086:0189 Intel Corp. 
Bus 002 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 0bc2:231a Seagate RSS LLC Expansion Portable
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 005: ID 1bcf:2b81 Sunplus Innovation Technology Inc. 
Bus 001 Device 004: ID 138a:0011 Validity Sensors, Inc. VFS5011 Fingerprint Reader
Bus 001 Device 003: ID 0bda:0138 Realtek Semiconductor Corp. RTS5138 Card Reader Controller
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Relevant part of dmesg just after connecting:

Code: Select all

[  159.662789] usb 4-2: new SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  159.687798] usb 4-2: New USB device found, idVendor=0bc2, idProduct=231a, bcdDevice= 7.10
[  159.687805] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  159.687809] usb 4-2: Product: Expansion
[  159.687813] usb 4-2: Manufacturer: Seagate
[  159.687815] usb 4-2: SerialNumber: NAARBWMC
[  159.695513] scsi host7: uas
[  159.696614] scsi 7:0:0:0: Direct-Access     Seagate  Expansion        0710 PQ: 0 ANSI: 6
[  159.698098] sd 7:0:0:0: Attached scsi generic sg3 type 0
[  167.213567] sd 7:0:0:0: [sdc] 7814037167 512-byte logical blocks: (4.00 TB/3.64 TiB)
[  167.213574] sd 7:0:0:0: [sdc] 4096-byte physical blocks
[  167.213781] sd 7:0:0:0: [sdc] Write Protect is off
[  167.213785] sd 7:0:0:0: [sdc] Mode Sense: 53 00 00 08
[  167.214142] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[  167.214731] sd 7:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
[  167.333326]  sdc: sdc1 sdc2
[  167.336113] sd 7:0:0:0: [sdc] Attached SCSI disk

Note that without trying to access the disk, no errors appear in dmesg.

So, I try to access the disk via ls:

Code: Select all

ls: cannot access 'Seagate': Input/output error
ls: cannot access 'Start_Here_Mac.app': No such file or directory
ls: cannot access 'Start_Here_Win.exe': No such file or directory
ls: cannot access 'Warranty.pdf': No such file or directory

And now dmesg has some errors!

Code: Select all

[ 1031.331021] sd 7:0:0:0: [sdc] tag#12 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN 
[ 1031.331034] sd 7:0:0:0: [sdc] tag#12 CDB: Read(16) 88 00 00 00 00 00 00 64 08 40 00 00 00 08 00 00
[ 1031.331048] xhci_hcd 0000:02:00.0: xHCI host controller not responding, assume dead
[ 1031.331065] usb 4-2: cmd cmplt err -108
[ 1031.331093] xhci_hcd 0000:02:00.0: HC died; cleaning up
[ 1031.331136] usb 4-2: USB disconnect, device number 2
[ 1031.333375] sd 7:0:0:0: [sdc] Synchronizing SCSI cache
[ 1031.354941] sd 7:0:0:0: Device offlined - not ready after error recovery
[ 1031.370995] blk_update_request: I/O error, dev sdc, sector 6555712 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 1031.371064] Buffer I/O error on dev sdc2, logical block 786440, async page read
[ 1031.372141] Buffer I/O error on dev sdc2, logical block 44, async page read
[ 1031.372379] Buffer I/O error on dev sdc2, logical block 44, async page read
[ 1031.372639] Buffer I/O error on dev sdc2, logical block 44, async page read
[ 1031.622995] sd 7:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

The drive spins down after 30 seconds, almost as if something has decided to put it to sleep. But whatever did that, didn't tell the rest of the system.

I have done a fair bit of googling and come up with auto_suspend as being a good place to start, but I cannot find how to control it on this kernel version.

The command
sudo echo -1 >/sys/module/usbcore/parameters/autosuspend
said 'permission denied'
(I know this would be a temporary fix, but it would prove the point)

Please, I don't know what to try next?

Thanks,

Chris.

[Moonstone Man]

... after 30 seconds, the power LED goes off, and then if I try to access the device, I get errors and dmesg shows some unhappiness.

That's a perennial problem with USB portable drives. The disk controller powers the drive down to save power, so it has nothing to do with Linux per se. The fix is to make the Linux USB driver command the drives to not suspend themselves. I see you're halfway there. Do it this way:

Code: Select all

sudo tee /etc/modprobe.d/usb-fix.conf <<< 'options usbcore autosuspend=-1'

Reboot.

[ChrisJC]

Hi,
Thanks for your reply.

Unfortunately that command does not make any difference!
I see a file has appeared in /etc/modprobe.d called usb-fix.conf which contains the text (without quotes) "options usbcore autosuspend=-1"

One other piece of information is that once the HDD has powered down, unplugging it from that USB port and reconnecting does not make it power up again. In fact, that USB port seems to be dead until I power-cycle.

What should I try next?

Thanks,

Chris.

[ChrisJC]

OK, some more effort has been expended, to no avail.
1. Add usbcore.autosuspend=-1 to the Kernel boot string via Grub.
2. Add usbcore.autosuspend_delay_ms=-1 to the Kernel boot string via Grub.
3. Add a file called usb.conf in /etc/modprobe.d containing options usbcore autosuspend=-1
4. Add a file called usb.conf in /etc/modprobe.d containing options usbcore autosuspend_delay_ms=-1

Observe the following facts:
/sys/module/usbcore/parameters/autosuspend is a file containing -1
grep PM_ /boot/config-5.4.0.42-generic has an awful lot of _PM_ parameters.
/boot/config-5.4.0.42-generic contains CONFIG_USB_UAS=m
/sys/bus/usb/devices/4-2/4-2:1.0/supports_autosuspend contains 0 (this file doesn't exist for long - once the drive is powered down, it's gone)
modprobe -c usbcore | grep autosuspend gives options usbcore autosuspend_delay_ms=-1

Any attempts to write to a file in /sys/bus/usb/devices/etc e.g. trying to write '0' to a file called control just results in Permission denied (I am using sudo).

What is next?

Chris.

[ChrisJC]

Bump - I am stuck.

Is there a fix for this?, I can't believe that I am the only person seeing this issue.

Chris.

[Moonstone Man]

Is there a fix for this?

Probably not. Not all USB to SATA controllers are created equal, some are very good and some are rubbish. There are only two things that I can think of that might help.

I can't believe that I am the only person seeing this issue.

Maybe you're one of a few stuck with a less than stellar USB/SATA controller.

Code: Select all

sudo apt-get install sdparm
sudo sdparm -a /dev/sdb

Where sdb is the problem device. Post the output of that. I'll take a look at it.

The only other thing that might work is buying a different controller, removing the drive from its case and trying the replacement controller. They can be picked up online for less than ten Australian pesos.

[Lert]

I only solved a similar problem (on a windows machine) by removing the HDD from the enclosure and connecting it via a $10 SATA to USB dongle from Amazon.. Worked fine ever after.

[Drugwash]

There may be another thing or two to try, in the idea that the issue may arise due to the drive drawing too much current from the USB port which forces the system to disable that port:
1. Replace original cable with a compatible Y patch cable that can draw current from two USB ports simultaneously;
2. Connect the drive through an externally powered USB hub.

You may also wanna search the web for user reports regarding that particular drive brand and model, maybe there is some known factory defect in the controller or something, which would mean you'd have to try a replacement SATA to USB bridge as advised above.

[ChrisJC]

Code: Select all

sudo sdparm -a /dev/sdb

Running sudo sdparm -a /dev/sdc emits the following:

Code: Select all

    /dev/sdc: Seagate   Expansion         0710
Caching (SBC) mode page:
  IC            0  [cha: n, def:  0, sav:  0]
  ABPF          0  [cha: n, def:  0, sav:  0]
  CAP           0  [cha: n, def:  0, sav:  0]
  DISC          1  [cha: n, def:  1, sav:  1]
  SIZE          0  [cha: n, def:  0, sav:  0]
  WCE           1  [cha: y, def:  1, sav:  1]
  MF            0  [cha: n, def:  0, sav:  0]
  RCD           0  [cha: n, def:  0, sav:  0]
  DRRP          0  [cha: n, def:  0, sav:  0]
  WRP           0  [cha: n, def:  0, sav:  0]
  DPTL          -1  [cha: n, def: -1, sav: -1]
  MIPF          0  [cha: n, def:  0, sav:  0]
  MAPF          -1  [cha: n, def: -1, sav: -1]
  MAPFC         -1  [cha: n, def: -1, sav: -1]
  FSW           0  [cha: n, def:  0, sav:  0]
  LBCSS         0  [cha: n, def:  0, sav:  0]
  DRA           0  [cha: n, def:  0, sav:  0]
  SYNC_PROG     0  [cha: n, def:  0, sav:  0]
  NV_DIS        0  [cha: n, def:  0, sav:  0]
  NCS           255  [cha: n, def:255, sav:255]
  CSS           0  [cha: n, def:  0, sav:  0]
Control mode page:
  TST           0  [cha: n, def:  0, sav:  0]
  TMF_ONLY      0  [cha: n, def:  0, sav:  0]
  DPICZ         0  [cha: n, def:  0, sav:  0]
  D_SENSE       0  [cha: n, def:  0, sav:  0]
  GLTSD         0  [cha: n, def:  0, sav:  0]
  RLEC          0  [cha: n, def:  0, sav:  0]
  QAM           1  [cha: n, def:  1, sav:  1]
  NUAR          0  [cha: n, def:  0, sav:  0]
  QERR          0  [cha: n, def:  0, sav:  0]
  RAC           0  [cha: n, def:  0, sav:  0]
  UA_INTLCK     0  [cha: n, def:  0, sav:  0]
  SWP           0  [cha: n, def:  0, sav:  0]
  ATO           0  [cha: n, def:  0, sav:  0]
  TAS           0  [cha: n, def:  0, sav:  0]
  ATMPE         0  [cha: n, def:  0, sav:  0]
  RWWP          0  [cha: n, def:  0, sav:  0]
  SBLP          0  [cha: n, def:  0, sav:  0]
  AUTOLOAD      0  [cha: n, def:  0, sav:  0]
  BTP           0  [cha: n, def:  0, sav:  0]
  ESTCT         0  [cha: n, def:  0, sav:  0]
Power condition mode page:
  PM_BG         0  [cha: n, def:  0, sav:  0]
  STANDBY_Y     0  [cha: n, def:  0, sav:  0]
  IDLE_C        0  [cha: n, def:  0, sav:  0]
  IDLE_B        0  [cha: n, def:  0, sav:  0]
  IDLE          0  [cha: n, def:  0, sav:  0]
  STANDBY       0  [cha: y, def:  1, sav:  0]
  ICT           0  [cha: n, def:  0, sav:  0]
  SCT           4294967286  [cha: y, def:3000, sav:4294967286]
  IBCT          0  [cha: n, def:  0, sav:  0]
  ICCT          0  [cha: n, def:  0, sav:  0]
  SYCT          0  [cha: n, def:  0, sav:  0]
  CCF_IDLE      0  [cha: n, def:  0, sav:  0]
  CCF_STAND     0  [cha: n, def:  0, sav:  0]
  CCF_STOPP     0  [cha: n, def:  0, sav:  0]
  

Is that illuminating?

I have ordered a Y cable just to see if that makes any difference.

Thankyou.

Chris.

[Moonstone Man]

Code: Select all

  STANDBY       0  [cha: y, def:  1, sav:  0]

Is that illuminating?

Yes, it is. The controller isn't necessarily a cheap and nasty, and standby is most certainly off, so the commands to turn it off did work. It might be a lack of power to the port you're using.

[ChrisJC]

Yes, it is. The controller isn't necessarily a cheap and nasty, and standby is most certainly off, so the commands to turn it off did work. It might be a lack of power to the port you're using.

Thankyou.

Well I have a suitable power lead on order, so I will give that a go and report back.

Chris.

[Moonstone Man]

Thankyou.

Not a problem. Just fyi so you can read the values in future...

Code: Select all

STANDBY       0  [cha: y, def:  1, sav:  0]

def: 1 means default on, and sav: 0 means that the current value is off, and cha: y means the default has been changed. Reading it as one sentence, STANDBY has changed from default on to off.

[ChrisJC]

Update - I got a Y lead from Amazon, and guess what, it works!!

Gives rise to a few thoughts:
1. Why is it not supplied with such a lead.
2. The shutting down after 30 seconds - is it an 'under the hood' feature of the USB driver that checks for overcurrent and then turns the peripheral off?, Does it log a message to that effect? What diagnostics are there to tell you (the advanced user) that such an event has occurred? Or is it all just completely silent?

Thanks.

Chris.

[Drugwash]

Glad you found a working solution, Chris.

As for your questions... the first one could lead to an ample discussion about why the world is so fracked up as it is. Won't open that can of worms now.

In regard to second question I'm not sure whether the protection lies within the software driver or the hardware itself. The fact that it only gets reset upon a reboot would point to the latter, but I may be wrong.

There are certain devices that attached to an USB port can display the supplied voltage and the current drawn by the peripheral attached to the device. I do have a couple such devices called "Charger Doctor" (there are also other brands/models) attached to my notebook. You may use one of those to check the output voltage with and without the drive attached, to see if the voltage drops significantly, and also what the peak current consumption may be (without the second Y lead connected, or using original cable).
Usually an USB port can sustain a max. of 500mA at ~5V. If voltage drops under 4.5V and/or current is higher than 500mA (0.5A) there you have it.

Going back to question one and excluding bad intentions on the side of the manufacturer there are a few possible reasons for the failure:
- bad quality cable (voltage drop due to high current on thin wires, for example)
- bad quality electronics components (capacitors leaking current, for example)
- disk specs out of limits (drawing more current than specified)
- internal SATA2USB bridge specs out of limits (as above)
- miscalculated combined consumption of bridge + disk (design fault)
They (Seagate) may not be aware of the problem, or they may just have to make do with the raw materials and components they are being provided with.

Anyway, the important thing is that it now works. Should it fail again in a relatively short time you may have to consider pulling the disk out of the enclosure and attaching it to an external SATA2USB bridge that uses an external power supply.
Fingers crossed, knock on wood and all that!