# USB 3.0 hub problems

## te36

I had similar issues in the past, but that was antique gentoo, antique HW, etc. so i gave up on USB 3.0 back then with hubs and stuck to 2.0.

Alas, now i have a new system rebuild, and still have the same problems:

USB 3.0 HDD connected via 7 port USB hub to USB 3.0 port on motherboard

% pv -ptera -L 90m < /dev/sdk > /dev/null

0:07:57 [88.5MiB/s] [  90MiB/s] [>                                                ]  2% ETA 5:45:19

pv: (stdin): read failed: Input/output error

There are no kernel errors when this happens. This happens with multiple disks, different type of USB 3.0 enclosures. When i reduce the rate-limiter ( -L XXXm - limit to XXX Megabye/sec) it takes longer to happen. Going below 50MByte/sec seems to make it go away.

This does not happen without a 3.0 USB hub but disk directly connected to MoBo 3.0 port. Cables are short and thick. 2 feet disk/hub cable, 2 feet hub/mobo cable. I tried with and without power supply on the USB 3.0 hub. No change. Also tested with just only a single disk connected to the hub, all other ports free. Problem still persists then.

I had one of the disks also connected via SATA and could read it from there at eg: 130 MByte/sec speed without any errors.

Mobo: E3C224D4I-14S,  4.4.26-gentoo kernel, gentoo sync from last month. 

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)

USB 3.0 Hub :   idVendor           0x2109,  idProduct          0x0812, iManufacturer           1 VIA Labs, Inc.,  iProduct                2 USB3.0 Hub             

HELP.

What else can i try to isolate the issue ? Any glorious parameters i could set anywhere ?

Don't want to start experimenting with many different USB 3.0 hubs, unless its known that some of them are the root cause for this - instead of something else.

----------

## Logicien

If you just remove the -L parameter does it work? I do not trust hubs. I ever loose data on a Usb key connected to a Usb hub. You can try

```
dcfldd if=/dev/sdk of=/dev/null
```

to see if there are input/output errors when the key is connected on the hub.

----------

## te36

 *Logicien wrote:*   

> If you just remove the -L parameter does it work? I do not trust hubs. I ever loose data on a Usb key connected to a Usb hub. You can try
> 
> ```
> dcfldd if=/dev/sdk of=/dev/null
> ```
> ...

 

Without -L i get I/O errors at the same rate as when i set the -L rate to maximum.

dcfldd if=/dev/sdk of=/dev/null

1911552 blocks (59736Mb) written.dcfldd:/dev/sdk: Input/output error

and repeating it, those errors happen at random sectors.

I do now get kernel errors:

[2016/11/06 15:31:18] usb 4-2: USB disconnect, device number 46

[2016/11/06 15:31:18] usb 4-2.1: USB disconnect, device number 47

[2016/11/06 15:31:19] usb 4-2.2: Failed to set U1 timeout to 0x0,error code -71

[2016/11/06 15:31:19] usb 4-2.2: usb_reset_and_verify_device Failed to disable LPM

[2016/11/06 15:31:19] usb 4-2.2: USB disconnect, device number 48

[2016/11/06 15:31:19] sd 38:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

[2016/11/06 15:31:19] sd 38:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 02 51 5a 30 00 00 1e 00

[2016/11/06 15:31:19] blk_update_request: I/O error, dev sdf, sector 311087488

[2016/11/06 15:31:19] sd 38:0:0:0: [sdf] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

[2016/11/06 15:31:19] sd 38:0:0:0: [sdf] tag#0 CDB: Read(10) 28 00 02 51 5a 4e 00 00 02 00

[2016/11/06 15:31:19] blk_update_request: I/O error, dev sdf, sector 311087728

[2016/11/06 15:31:19] sd 41:0:0:0: [sdk] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

[2016/11/06 15:31:19] sd 41:0:0:0: [sdk] tag#0 CDB: Read(10) 28 00 00 b7 46 00 00 00 f0 00

[2016/11/06 15:31:19] blk_update_request: I/O error, dev sdk, sector 12011008

*sigh*

again, not errors without hub.

----------

## NeddySeagoon

te36,

How is your USB HDD powered?

Tell us the make and model of the HDD(s).

----------

## Anon-E-moose

Is the usb hub powered or does it take it's power from the computers usb port?

How many devices are on the usb hub?

And as Neddy asked, is the usb hdd powered?

All these can affect the problem.

Edit to add: the thing they all have in common is that you're probably not getting enough power to the hdd to run it properly.

----------

## te36

As said, i tried to run hub bus powered and powered via external power supply, 5V.

HDD for example external 3.5" 4GByte Seagate disk, ST4000DM000-1F2168.

My only theory is also about the power levels. The USB 3.0 3.5" external HDD have all only

an external 12V power supply. I wonder how they get their 5V power. If they get it from the USB bus, then the 5V from the hub could be the problem. But that theory would also only make sense if the 5V is used for any of the mechanical movements parts in the HDDs. No idea how to prove the theory. Solder a big capacitor between hub and one of the HDDs... hmm.

----------

## NeddySeagoon

te36,

An external 12v power brick will provide 12v for the drive spin motor and will be down converted to 5v for everything else.

You don't need to prove it.  Look at the 

```
MaxPower                2mA
```

entry in 

```
lsusb -vvv
```

 for the device.

That's the power it draws from the USB bus.

Bus powered rotating rust hard drives have always been a problem.  The USB bus struggles to provide spin motor power.

This is not your use case.

Do you have any power management enabled?

USB disconnect could be caused by the power management believing the device is idle, when its really not.

----------

## te36

 *NeddySeagoon wrote:*   

> te36,
> 
> An external 12v power brick will provide 12v for the drive spin motor and will be down converted to 5v for everything else.
> 
> You don't need to prove it.  Look at the 
> ...

 

Ok. thanks for explaining. Yes, I see the 2 mA. I guess that's just a declared value by the drive, not measured, but it should be trustworthy. There goes my theory.

 *NeddySeagoon wrote:*   

> Do you have any power management enabled?
> 
> USB disconnect could be caused by the power management believing the device is idle, when its really not.

 

Not that I am aware. Any checklist what I could do to disable all applicable power management ?

----------

