[Solved?] External harddisk usb connection falters, slumps and dies

chochem · 2008-08-20 18:30:06

I've got a problem with a Western Digital MyBook: In the middle of a fast transfer, the connection will slow to a crawl and if cancelled will cause the harddisk to go into a lengthy 'occupied' state at the end of which the disk will not only have unmounted but also been lost to udev.

Here the dmesg (just to be specific: the error messages do not appear at the time of the slowdown, only when the transfer is cancelled)

usb 1-3: reset high speed USB device using ehci_hcd and address 3
usb 1-3: device not accepting address 3, error -110
usb 1-3: reset high speed USB device using ehci_hcd and address 3
usb 1-3: device not accepting address 3, error -110
usb 1-3: reset high speed USB device using ehci_hcd and address 3
usb 1-3: device not accepting address 3, error -110
usb 1-3: reset high speed USB device using ehci_hcd and address 3
usb 1-3: device not accepting address 3, error -110
usb 1-3: USB disconnect, address 3
sd 2:0:0:0: Device offlined - not ready after error recovery
sd 2:0:0:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sdb, sector 165521259
Buffer I/O error on device sdb1, logical block 165521196
lost page write due to I/O error on sdb1
sd 2:0:0:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00
end_request: I/O error, dev sdb, sector 238507
FAT: Directory bread(block 238444) failed
(repeated ad nauseam...)
FAT: unable to read inode block for updating (i_pos 2648339139)
Buffer I/O error on device sdb1, logical block 165521196
lost page write due to I/O error on sdb1

I'll have to reboot to remount it properly. Restarting the ehci_hcd module can prompt attempts to reconnect, although they inevitably fail:

usb 1-3: new high speed USB device using ehci_hcd and address 4
usb 1-3: device not accepting address 4, error -110
usb 1-3: new high speed USB device using ehci_hcd and address 5
usb 1-3: device not accepting address 5, error -110
usb 1-3: new high speed USB device using ehci_hcd and address 6
usb 1-3: device not accepting address 6, error -110
usb 1-3: new high speed USB device using ehci_hcd and address 7
usb 1-3: device not accepting address 7, error -110
hub 1-0:1.0: unable to enumerate USB device on port 3

I have no clue as to what causes it - I cannot identify any particularities about the circumstances. Sometimes I can shift several gigabytes with no problem but mostly it will fail sooner or later. It has persisted over changing cables, a change of distrobution (ubuntu hardy to arch) and various filesystem formats (ntfs, ext3, fat32 currently).

Any help appreciated.

Last edited by chochem (2008-09-04 22:13:04)

pheon · 2008-08-20 20:22:50

Hello,
this additional information might be usefull, too:
- did this came up from one day to another?
- can you reproduce this problems on another computer?
- does your model has an external power supply?

usb 1-3: reset high speed USB device using ehci_hcd and address 3
usb 1-3: device not accepting address 3, error -110

Please try to boot the kernel with irqpoll or noapic options. In some cases this fixes IRQ-related problems.
Aslo check to what the operatingsystem is set in the BIOS (win/linux/other/...).

Checking the HDD with WD's Data Lifeguard (see this page for an error-code list) might rule out a defect HDD - in case you have access to a windows box. Otherwise check e2fsprogs and smartmontools.

I am not completely sure, if this is hardware or software related....

Hope this helps isolating the problem.

Br

chochem · 2008-08-21 07:25:46

Hi pheon, thanks for replying.

Yes, the drive des have an external power supply and I have on occasion lent it to a friend with a Mac to move her music collection around and I haven't heard any complaints. Furthermore, I've never expereienced anything similar when I've booted into Windows.

I tried adding irqpoll and noapic to the kernel arguments. I tested a few transfers which went ok but rather slowly (around 1-2 Mb/s I'd say) However, a seeming byproduct of the these arguments was the computer becoming slow to respond, annoying sound glitches when moving from one desktop to another and an initial flurry of harddisk activity that made it hard to do anything (though excactly what the arguments are repsonsible for, I am not sure). I tried removing irqpoll and found that the anoyances were gone. Transfers are still not exactly lightning speed:

sudo hdparm -Tt /dev/sdb1
Password: 

/dev/sdb1:
 Timing cached reads:   578 MB in  2.00 seconds = 288.47 MB/sec
 Timing buffered disk reads:   12 MB in  3.01 seconds =   3.99 MB/sec

and as for stability, I cannot tell yet.

But you raise a valid point - I'll try running some tests later and see what I find.

apaige · 2008-08-21 07:50:33

I've had the same issue with USB flash drives. It has also been reported numerous times to the linux kernel mailing list as well Ubuntu's bug tracker. Maybe the devices are to blame for flaky implementations, but if Windows users had the same problems USB would have gotten a much worse reputation by now, so I'm inclined to blame the kernel's implementation of EHCI, USB mass storage or whatever, be it by lack of proper documentation from vendors.

USB storage has proved highly unreliable for me, to the point that I can't store anything of value through USB. That is, through USB 2, because USB 1 (i.e., UHCI/OHCI) has never caused me any problem. Of course, that's unbearably slow :-/

pheon · 2008-08-21 11:10:32

chochem wrote:

I tried adding irqpoll and noapic to the kernel arguments. I tested a few transfers which went ok but rather slowly (around 1-2 Mb/s I'd say) However, a seeming byproduct of the these arguments was the computer becoming slow to respond, annoying sound glitches when moving from one desktop to another and an initial flurry of harddisk activity that made it hard to do anything (though excactly what the arguments are repsonsible for, I am not sure). I tried removing irqpoll and found that the anoyances were gone. Transfers are still not exactly lightning speed:
sudo hdparm -Tt /dev/sdb1
Password: 

/dev/sdb1:
 Timing cached reads:   578 MB in  2.00 seconds = 288.47 MB/sec
 Timing buffered disk reads:   12 MB in  3.01 seconds =   3.99 MB/sec

As far as I know, irqpoll is responsible for this, although it should not cause a decrease in performance to this extend. I remember of reading something on the LKML stating irqpoll should barely be notable on a desktop-system.

Please check to what the OS is set in the BIOS. Wrong apci messages might confuse the kernel.

br

chochem · 2008-08-21 11:46:53

pheon wrote:

As far as I know, irqpoll is responsible for this, although it should not cause a decrease in performance to this extend. I remember of reading something on the LKML stating irqpoll should barely be notable on a desktop-system.

I should probably have tested that option a bit more thoroughly before reporting. I'm thinking that at least the initial HD activity might have been due to the transmission-daemon not having been properly terminated last time and therefore starting to verify files.

pheon wrote:

Please check to what the OS is set in the BIOS. Wrong apci messages might confuse the kernel.
br

Sorry forgot about that: I checked the bios and didn't find any references to OS, other than the option to enable legacy USB for the benefit of 'pre-USB systems' like 'DOS and UNIX'. I tried disabling it along with the kernel arguments , though it makes for somewhat less stringent testing. With this option off and the NOACPI argument I have had transfer crashes though not as violent as usual: In transferring a 700 Mb AVI file to the drive it came to a standstill (for all practiacal purposes) around 95% and I cancelled it (Thunar). However, I was still able to browse the drive.

chochem · 2008-08-29 21:26:47

I finally left it in windows overnight to do it the WD test. No errors reported....

chochem · 2008-08-30 18:42:56

Okay, since I got my acpi problem solved, I figured it might have a positive side effect on the other issues... Not so, as it turned out. I did however, give various boot param setups a new shot. My findings:

- The only sure setup seems to be the noapic irqpoll whic has the nasty side effect of making the computer irresponsive and slow.
- Running my webcam (gspca) side by side with transfers showed that the two connections die at the same time. I don't know what this proves - that it is a usb issue and not a hardware one? Or just that the whatever it is that's causing it, knocks out all connections?

EDIT: On a possibly related subject: It turned out that my nci module (b44) was creating a lot of problems, causing my internet connection to fail again and again. Since I turned it off and switched to using only wireless, the system has been a lot better behaved. It might also remove the cause of this problem (although network outages and usb outages did not go hand in hand) but I can't really test it anymore as I've moved the harddisk to the router, mounting it via NFS.

Last edited by chochem (2008-09-04 22:12:23)

chochem · 2008-09-18 22:57:22

Yeah that's a nice quick-fix, Stonekeeper, but it will mean connecting at osme pretty low speeds if you consider it a solution.

Arch Linux

#1 2008-08-20 18:30:06

[Solved?] External harddisk usb connection falters, slumps and dies

#2 2008-08-20 20:22:50

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#3 2008-08-21 07:25:46

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#4 2008-08-21 07:50:33

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#5 2008-08-21 11:10:32

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#6 2008-08-21 11:46:53

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#7 2008-08-29 21:26:47

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#8 2008-08-30 18:42:56

Re: [Solved?] External harddisk usb connection falters, slumps and dies

#9 2008-09-18 22:57:22

Re: [Solved?] External harddisk usb connection falters, slumps and dies

Board footer