[Bugme-new] [Bug 8968] New: One broken USB storage device can hang the entire USB subsystem

[bugme-daemon at bugzilla.kernel.org]

http://bugzilla.kernel.org/show_bug.cgi?id=8968

           Summary: One broken USB storage device can hang the entire USB
                    subsystem
           Product: IO/Storage
           Version: 2.5
     KernelVersion: 2.6.22.6
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
        AssignedTo: io_other at kernel-bugs.osdl.org
        ReportedBy: kernel at misc.lka.org.lu


I have several Sharkoon external disk enclosures.

One contains an IDE (parallel) disk with some bad sectors. The other contains a
good (as far as I know...) SATA disk.

With the IDE disk, If I attempt to read files containing the bad sectors, the
process hangs forever, in an unkillable state.

With the SATA disk (new, and never fell => no reason to believe it is bad), it
fails randomly after some heavy copying (rsyncing a huge tree from the external
disk towards my internal disk), at different places on each try. But like with
the IDE disk, the process will hang forever, in an unkillable state, and the
drive's light turns green (red with Ubuntu kernel 2.6.22-10-generic).

In both cases (IDE and SATA), a sync started in another window will also hang
forever (even if the first process did only read from the disk). Attempting to
remove the ohci_hcd or ehci_hcd will just cause that rmmod process to hang as
well. Lsusb will hang likewise. But strangely enough, my usb mouse still works,
as do my usb speakers.

With the IDE disk, a reboot solves the issue (until I attempt read those bad
sectors again), even without powercycling the disk.

IMHO, these Sharkoon enclosures do have issues, but should the kernel really
handle the situation so badly? Shouldn't there be a timeout where the processes
will just get an I/O error, but the rest of the system can continue using USB?

Interestingly enough, the problem doesn't occur (or occurs much less often) if
I throttle rsync's bandwith using the --bwlimit option (if I throttle bw to 5
Megabytes/s, the problem almost never happens. The enclosure+disk is capable of
30 Megabyte/s though)


Most recent kernel where this bug did not occur: don't known for sure. However,
on my old SuSE box (having 2.6.13-15.16) it does work all right.

Distribution: Kubuntu Gutsy

Hardware Environment: 
Sharkoon Swift-Case SATA/USB2.0 3.5"
http://www.computeruniverse.net/info.asp?id=90205832

Western Digital WD2500JS 250GB
http://www.computeruniverse.net/info.asp?id=90143746

or, for the IDE variant:
Sharkoon Swift-Case USB2.0 3.5"
http://www.computeruniverse.net/info.asp?id=90150304

MAXTOR 6L080J4

In both cases, with an ASUS M2A-VM, Sockel AM2, mATX motherboard
http://www.computeruniverse.net/info.asp?id=90216021
(in case it is relevant due to the USB controller?)


Software Environment: n.a.

Problem Description:
A copy from the affected device will hang in D (diskio) state, and is
unkillable

Steps to reproduce:
rsync -uav /media/usbdisk /tmp

(For the IDE variant: knock over the drive while in operation or otherwise
create damaged sectors...)


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.