Bug 8639
| Summary: | new external hd case COOLER MASTER X-Craft 360 with 750 GO sata hd (ST3750640A) not working | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | James PEARSON (pearson55j) |
| Component: | USB | Assignee: | Jan Gutter (kernel) |
| Status: | REJECTED DOCUMENTED | ||
| Severity: | normal | CC: | kernel |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | kernel 2.6.18.8-0.3-default and 2.6.22-rc4-git3-2-default | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 5089 | ||
|
Description
James PEARSON
2007-06-16 06:38:44 UTC
This has also been reported by various people on the Cooler Master forums: http://forum.coolermaster.com/viewtopic.php?t=8487 I've got a similar issue with my X-Craft enclosure for a laptop SATA drive. This one's USB powered, and the USB ID is ed06:8000. (Manufacturer ID according to lsusb is DATAST0R) It works in 2.6.23, but it gives very similar errors in 2.6.24: device descriptor read/64, error -32 device not accepting address 5, error -110 I've verified this on more than one Intel chipset (a Thinkpad and an Acer). I haven't attempted a git-bisect yet... I'll try to do a debug run before that though, to check if there's a simple gotcha. Do you think the bugs might be related? Ok, a git-bisect done lazily over this weekend didn't yield results... Either I messed up (likely) or the problem is intermittent... Anyway, here's the snippets of dmesg with CONFIG_USB_DEBUG=y BOTH: usb usb1: usb resume ehci_hcd 0000:00:1a.7: resume root hub hub 1-0:1.0: hub_resume hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0000 ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 3, status 0501, change 0001, 480 Mb/s hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501 ehci_hcd 0000:00:1a.7: port 3 high speed ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT usb 1-3: new high speed USB device using ehci_hcd and address 4 ehci_hcd 0000:00:1a.7: devpath 3 ep0in 3strikes 2.6.23 (working): ehci_hcd 0000:00:1a.7: port 3 high speed ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT usb 1-3: default language 0x0409 usb 1-3: new device strings: Mfr=16, Product=32, SerialNumber=48 usb 1-3: Product: SATA8000 FW1.0 usb 1-3: Manufacturer: DATAST0R Technology Corp usb 1-3: SerialNumber: 1966051022645658 usb 1-3: uevent usb 1-3: usb_probe_device usb 1-3: configuration #1 chosen from 1 choice usb 1-3: adding 1-3:1.0 (config #1, interface 0) 2.6.24 (broken): ehci_hcd 0000:00:1a.7: devpath 3 ep0in 3strikes ehci_hcd 0000:00:1a.7: port 3 high speed ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT usb 1-3: device descriptor read/64, error -32 ehci_hcd 0000:00:1a.7: port 3 high speed ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT usb 1-3: device descriptor read/64, error -32 Just to avoid confusion, 2.6.24 prints two lines of the following: ehci_hcd 0000:00:1a.7: devpath 3 ep0in 3strikes Do your enclosure(s) give the same results? Ok, I've finally gotten a plausible run on git-bisect. This time I made *sure* that I tested multiple times, without hald running and with another hard drive. The first commit where the error happens is: commit 14c04c0f88f228fee1f412be91d6edcb935c78aa Author: Alan Stern <stern@rowland.harvard.edu> Date: Fri Aug 24 15:40:19 2007 -0400 USB: reorganize urb->status use in ehci-hcd This patch (as974) reorganizes the way ehci-hcd sets urb->status. It now keeps the information in a local variable until the last moment. The patch also simplifies the handling of -EREMOTEIO, since the only use of that code is to set the do_status flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> From the patch, it seems that urb->status is passed via the stack now, eliminating two spinlocks... I'm going to try adding these spinlocks to 2.6.24 just for the heck of it to see if it's a timing issue. Anybody else watching this bug with ANY other news? Ok, after reverting the following patches, I've had success! remove traces of urb->status from usbcore: e015268d2fcfcaef70a1ec535e6381f75aafbf81 get rid of urb->lock: 1431d2a44ccf68a547094976f363f94177ab00c6 Eliminate urb->status usage: 4a00027dcb088bf90fa8fb14a7e8ba3506d78f22 reorganize urb->status use in usbmon: 9347d51c52afcf1a77d2104f162cf8a085624c83 reorganize urb->status use in r8a66597-hcd: 888fda47051716765175d0008450126c837adb32 reorganize urb->status use in sl811-hcd: 65e51098d9094c7e840b6d6291867b95538d9442 reorganize urb->status use in ohci-hcd: 55d8496837cf124f68656e4242a5e20eb592fd54 reorganize urb->status use in ehci-hcd: 14c04c0f88f228fee1f412be91d6edcb935c78aa reorganize urb->status use in dummy-hcd: 4d2f110c51eec853c50f68cf068888a77551c8d3 The "new" dmesg looks like this: usb usb1: usb resume ehci_hcd 0000:00:1a.7: resume root hub hub 1-0:1.0: hub_resume hub 1-0:1.0: state 7 ports 4 chg 0000 evt 0000 ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001803 POWER sig=j CSC CONNECT hub 1-0:1.0: port 3, status 0501, change 0001, 480 Mb/s hub 1-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501 ehci_hcd 0000:00:1a.7: port 3 high speed ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT usb 1-3: new high speed USB device using ehci_hcd and address 3 (previously it repeated this line twice:) ehci_hcd 0000:00:1a.7: devpath 3 ep0in 3strikes ehci_hcd 0000:00:1a.7: port 3 high speed ehci_hcd 0000:00:1a.7: GetStatus port 3 status 001005 POWER sig=se0 PE CONNECT usb 1-3: default language 0x0409 usb 1-3: uevent usb 1-3: usb_probe_device Two possibilities left: 1) It's a timing issue and a quirk needs to be added for this specific device 2) It's a logic issue: the new code handles a specific case slightly different than the old code. I'll see if I can set aside some time to actually trace the logic in the code... Ok, I've finally found the solution my problem! The nice people at linux-usb (Misha Zhilin and Alan Stern) found a small difference between the way that 2.6.23 and 2.6.24 handled certain types of errors. It seems that one of the rare devices that is affected by this is the good ol' DATAST0R chip that's in my X-Craft enclosure. Anyone still having a problem, please check out: http://marc.info/?l=linux-usb&m=120370800915849&w=2 and apply the patch (it moves a line in drivers/usb/host/ehci-q.c) There's another workaround available that works on non-patched kernels too. It's actually simple (if inconvenient): just power up the drive for 3 seconds before plugging in the data connection. On my USB-powered enclosure, I did it by plugging in the power USB plug, but I'm sure if the bug is the same on the large enclosure, applying external power for 3 seconds would work around the bug too. If there isn't any feedback on this bug soon, I think it should be closed when the patch in #6 hits a stable kernel. Ok, 2.6.24.4 has this fix, as well as mainline on the unreleased 2.6.25 branch. I've received no chatter from anyone, so I vote this bug can be closed! Special thanks to Alan Stern and Misha Zhilin! The problem is not resolved completely with patches mentioned in this bug. I posted a patch to linux-usb mailing list http://article.gmane.org/gmane.linux.usb.general/9959 which solves the timeout problem for me. Heh.. right, this problem still exists on my 2.6.25-gentoo-r7 SMP x86_64 kernel. However, comment #7 worked for me. When starting the drive while already connected, usb 1-1: new high speed USB device using ehci_hcd and address 21 usb 1-1: device descriptor read/64, error -32 usb 1-1: device descriptor read/64, error -32 usb 1-1: new high speed USB device using ehci_hcd and address 22 usb 1-1: device descriptor read/64, error -32 usb 1-1: device descriptor read/64, error -32 usb 1-1: new high speed USB device using ehci_hcd and address 23 usb 1-1: device not accepting address 23, error -110 usb 1-1: new high speed USB device using ehci_hcd and address 24 usb 1-1: device not accepting address 24, error -110 hub 1-0:1.0: unable to enumerate USB device on port 1 usb 3-1: new full speed USB device using ohci_hcd and address 10 usb 3-1: device descriptor read/64, error -32 usb 3-1: device descriptor read/64, error -32 usb 3-1: new full speed USB device using ohci_hcd and address 11 usb 3-1: device descriptor read/64, error -32 usb 3-1: device descriptor read/64, error -32 usb 3-1: new full speed USB device using ohci_hcd and address 12 usb 3-1: device not accepting address 12, error -110 usb 3-1: new full speed USB device using ohci_hcd and address 13 usb 3-1: device not accepting address 13, error -110 hub 3-0:1.0: unable to enumerate USB device on port 1 When switching it on before connecting, waiting 10 seconds, then connecting to the USB, i get usb-storage: device found at 30 usb-storage: waiting for device to settle before scanning scsi 16:0:0:0: Direct-Access SAMSUNG HD501LJ CR10 PQ: 0 ANSI: 0 sd 16:0:0:0: [sdk] 976773168 512-byte hardware sectors (500108 MB) sd 16:0:0:0: [sdk] Write Protect is off sd 16:0:0:0: [sdk] Mode Sense: 00 08 00 00 sd 16:0:0:0: [sdk] Assuming drive cache: write through sd 16:0:0:0: [sdk] 976773168 512-byte hardware sectors (500108 MB) sd 16:0:0:0: [sdk] Write Protect is off sd 16:0:0:0: [sdk] Mode Sense: 00 08 00 00 sd 16:0:0:0: [sdk] Assuming drive cache: write through sdk: sdk1 sd 16:0:0:0: [sdk] Attached SCSI disk sd 16:0:0:0: Attached scsi generic sg10 type 0 usb-storage: device scan complete Here;s some info, # uname -a Linux sempronstein 2.6.25-gentoo-r7 #6 SMP Wed Sep 10 16:37:29 BST 2008 x86_64 AMD Sempron(tm) Processor LE-1200 AuthenticAMD GNU/Linux emerge --info Portage 2.1.4.4 (default/linux/amd64/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.25-gentoo-r7 x86_64) ================================================================= System uname: 2.6.25-gentoo-r7 x86_64 AMD Sempron(tm) Processor LE-1200 Timestamp of tree: Mon, 15 Sep 2008 11:00:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p33 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CXXFLAGS="-O2 -pipe" LDFLAGS="-Wl,-O1" Xushi, did you apply the patch in #9? To be quite honest, I haven't had this problem for quite a while... My cables are going bad lately, though: any idea where to find a "short" high-power USB cable like the ones that shipped with my mobile USB drives? It also doesn't help that I live in South Africa... ho hum.... I have noticed that 2.6.26-gentoo-r1 tends to negotiate stuff down to USB1.1, but it might be my aforementioned bad cables, the weather or something entirely different. |