Bug 369271 - USB drive is reset during copying (ehci)
USB drive is reset during copying (ehci)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-06 18:45 EST by Edek Pienkowski
Modified: 2007-12-07 19:14 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-07 18:40:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Edek Pienkowski 2007-11-06 18:45:50 EST
Description of problem: USB drive (enclosure 2.5') stops copying large files.


Version-Release number of selected component (if applicable): present in kernels
from FC4 up till now (FC8-rc2). I never tried a vanilla kernel.


How reproducible:
Buy an ASUS A6K laptop and a right USB enclosure ;) plug in the drive and start
copying. After some time (depends, sometimes over 1GB) copying stops, "bus
reset" in dmesg, device looses power for quite a few seconds.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Copying stops

Expected results:
Copying succeedes

Additional info: if ehci_hcd is removed everything is fine, but too slow
[root@tur parameters]# lsusb
Bus 004 Device 007: ID 0402:5637 ALi Corp. M5637 IDE Controller
Bus 004 Device 004: ID 174f:a311  
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 003: ID 046d:c521 Logitech, Inc. 
Bus 003 Device 001: ID 0000:0000  
Bus 002 Device 003: ID 0a5c:2101 Broadcom Corp. 
Bus 002 Device 001: ID 0000:0000  

USB sticks work fine. No module/kernel options I tried so far fix the issue.

If needed, I can hack the ehci module to dump debugging traces to analyze the
problem (at least the cause of reset, if it is not hardware - is there a
possibility that hardware for some reasons cuts the power, maybe because of
overcurrent?).
Comment 1 Pete Zaitcev 2007-11-06 19:28:07 EST
These days there's almost no chance to use an enclosure off the 500 mA
supply in the root hub (if that -- some laptops do not have it right).
This is why enclosures come with the "dual" cables and other such nonsense.
I have a couple of 5V power supplies to support my enclosures.
I have one 2.5" enclosure which seems to be content on the built-in
power, but it's rather an exception. YMMV, but I suggest finding an
external power supply.

I don't think kernel can do much about this sort of thing, unless we find
that this is some sort of specific bug, e.g. a reset bit wired to power
in your laptop's root hub. Then something can be blacklisted.
Comment 2 Edek Pienkowski 2007-12-07 18:40:34 EST
Thanks. I bought an "active" USB hub. However, it fixes a problem only
partially. I guess it is not a kernel problem, so I will close the bug.

So I'll describe the effects. The hub comes with 5V 500mA power supply. Since it
is a 7 port USB hub (two 4 port hubs interconnected), I would expect it to be
more like a 3.5 A power supply, but that is a digression. The good thing is that
it has the same plug as the USB-to-power 2nd enclosure wire, so I can plug it
into the drive enclosure. I tried two configurations
a) power supply to the hub; laptop to the hub; enclosure to the hub.
b) power supply to the enclosure; laptop to the hub; enclosure to the hub
I leave other possibilities for later.

In both a) and b) the result is the same: copying sometimes stops (the lights on
the enclosure turn off, copying stops, but the drive inside is still spinning,
which I can tell by the subtle vibration of the enclosure); however, and this is
a change, as far as kernel is concerned, the drive is _not_ disconnected. When
the lights on the enclosure come back again (after quite a few seconds), the
copying continues. I am not 100% sure that it really puts the data into the
right place (I do `dd` to a partition to fill it with random data before putting
an encrypted ext2 on it). I'll check real filesystem operations later. 

Anyway, the stops are more rare than before (once or twice during 31GB, instead
of once per 0.5 - 4 GB ), and operation continues. I'll check what happens with
filesystem operations later.

There are two more side effects: sometimes, after being turned on or connected,
the drive is not recognized (the scsi layer does not kick in). 

Once, the disk started doing click-click <1s interval> click-click and so on
forever. Then it has to be powered down and up, breaking everything that was in
progress. The same click-click happens when it is not recognized after being
turned on.

Since I (usually ;) ) think logically, the above is hard to explain by what I
know and I do not know much about USB. Ok, my hub is cheap, my drive enclosure
is cheap, so they can both be crap (not that I know which enclosures or hubs are
better than others, I have no experience).

Any ideas how to improve the situation? They would be most welcome. Because from
what I see, I need to buy a better enclosure, is it not so?

Comment 3 Pete Zaitcev 2007-12-07 19:14:16 EST
It's hard to find a decent enclosure these days. It would be the best,
but the situation is that you cannot trust brands even (e.g. WD).
I had a decent luck with enclosures which come with a drive inside.
The one which I am using now has a 2.5A power supply (switching type,
not a transformer).

Note You need to log in before you can comment on or make changes to this bug.