Suject: new external hd case COOLER MASTER X-Craft 360 with 750 GO sata hd (ST3750640A) not working Problem Description: new external hd case COOLER MASTER X-Craft 360 - 3.5" - USB2.0 and eSATA - for SATA hd (RX-360-STBA-GP) is not working under usb 2.0 note I have installed a SEAGATE 750 GO sata hd (ST3750640A). Everythng works fine under Windows XP. The hd ST3750640A works ok with COOLER MASTER X-Craft 350 (350 != 360) case. The COOLER MASTER X-Craft 360 is a new case without a new "slide in" the hard drive design I have this problem with 3 different computers Tyan Tiger MPX (S2466) running opensuse 10.2 (kernel 2.6.18.8-0.3-default) T40 Thinkpad running opensuse 10.3 alpha4 and 10.3 alpha5 (2.6.22-rc4-git3-2-default) T60 Thinkpad running opensuse 10.2 (kernel 2.6.18.8-0.3-default) wWhen I googled I found a simular looking bug "[Bug 8444] New: 16GB USB Stick not working" (see below for bug extract) that was marked solved - an extract follows... Re: [linux-usb-devel] [Bugme-new] [Bug 8444] New: 16GB USB Stick not working Index: usb-2.6/drivers/usb/core/hub.c This was the solution: - (i ? USB_CTRL_GET_TIMEOUT : 1000)); + USB_CTRL_GET_TIMEOUT); Executive summary : Despite the fact that the above modification for [Bug 8444] "USB_CTRL_GET_TIMEOUT)" is incorporated in the 10.3 alpha5 (2.6.22-rc4-git3-2-default) kernel see "2230 USB_CTRL_GET_TIMEOUT);" I still have the same problem (.e.g external hd case COOLER MASTER X-Craft 360 doesn't work). ################################################################################## # dmesg lists this after I plug the external COOLER MASTER X-Craft 360 case ################################################################################## 0A003F87B10000000001030307) usb 3-4: new high speed USB device using ehci_hcd and address 3 usb 3-4: device descriptor read/64, error -32 usb 3-4: device descriptor read/64, error -32 usb 3-4: new high speed USB device using ehci_hcd and address 4 usb 3-4: device descriptor read/64, error -32 usb 3-4: device descriptor read/64, error -32 usb 3-4: new high speed USB device using ehci_hcd and address 5 usb 3-4: device not accepting address 5, error -110 usb 3-4: new high speed USB device using ehci_hcd and address 6 usb 3-4: device not accepting address 6, error -110 ################################################################################## # dmesg lists this after I plug a 2 Go Crucial usb key ################################################################################## Initializing USB Mass Storage driver... scsi2 : SCSI emulation for USB Mass Storage devices usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usb-storage: device found at 7 usb-storage: waiting for device to settle before scanning scsi 2:0:0:0: Direct-Access Crucial Gizmo! overdrive 2.00 PQ: 0 ANSI: 2 sd 2:0:0:0: [sdb] 3996160 512-byte hardware sectors (2046 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 03 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sd 2:0:0:0: [sdb] 3996160 512-byte hardware sectors (2046 MB) sd 2:0:0:0: [sdb] Write Protect is off sd 2:0:0:0: [sdb] Mode Sense: 03 00 00 00 sd 2:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sd 2:0:0:0: [sdb] Attached SCSI removable disk sd 2:0:0:0: Attached scsi generic sg2 type 0 usb-storage: device scan complete ############################################################################################################ # Tyan Tiger MPX (S2466) running opensuse 10.2 (kernel 2.6.18.8-0.3-default) ############################################################################################################ jpearson@bigboy:/> find / -name "hub.c" -print 2>/dev/null /usr/src/linux-2.6.18.8-0.3/drivers/usb/core/hub.c jpearson@bigboy:/> kernel 2.6.18.8-0.3-default tyan mb Tiger 2466 FOUND for (j = 0; j < 3; ++j) { buf->bMaxPacketSize0 = 0; r = usb_control_msg(udev, usb_rcvaddr0pipe(), USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, GET_DESCRIPTOR_BUFSIZE, (i ? USB_CTRL_GET_TIMEOUT : 1000)); ************** switch (buf->bMaxPacketSize0) { case 8: case 16: case 32: case 64: if (buf->bDescriptorType == USB_DT_DEVICE) { r = 0; break; } /* FALL THROUGH */ default: if (r == 0) r = -EPROTO; break; } if (r == 0) break; } ============================================================================== This was the solution: - (i ? USB_CTRL_GET_TIMEOUT : 1000)); + USB_CTRL_GET_TIMEOUT); ============================================================================== ############################################################################################################ # T40 Thinkpad running opensuse 10.3 10.3 alpha5 (2.6.22-rc4-git3-2-default) ############################################################################################################ 224 for (j = 0; j < 3; ++j) { 2225 buf->bMaxPacketSize0 = 0; 2226 r = usb_control_msg(udev, usb_rcvaddr0pipe(), 2227 USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, 2228 USB_DT_DEVICE << 8, 0, 2229 buf, GET_DESCRIPTOR_BUFSIZE, 2230 USB_CTRL_GET_TIMEOUT); ************** 2231 switch (buf->bMaxPacketSize0) { 2232 case 8: case 16: case 32: case 64: case 255: 2233 if (buf->bDescriptorType == 2234 USB_DT_DEVICE) { =================================================================== I have : (i ? USB_CTRL_GET_TIMEOUT : 1000)); OLD - (i ? USB_CTRL_GET_TIMEOUT : 1000)); NEW + USB_CTRL_GET_TIMEOUT); Index: usb-2.6/drivers/usb/core/hub.c =================================================================== ################################################################################## # Bug reference found when I googled... ################################################################################## Re: [linux-usb-devel] [Bugme-new] [Bug 8444] New: 16GB USB Stick not working Date: Mon, 7 May 2007 11:10:31 -0700 From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Subject: Re: [linux-usb-devel] [Bugme-new] [Bug 8444] New: 16GB USB Stick not working On Mon, 7 May 2007 08:52:37 -0700 bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8444 > > Summary: 16GB USB Stick not working > Kernel Version: 2.6.21.1 > Status: NEW > Severity: normal > Owner: greg@xxxxxxxxx > Submitter: mrb74@xxxxxx > > > Distribution: > Debian Unstable > > Hardware Environment: > Dell Precision 300 > > 00:00.0 Host bridge: Intel Corporation 82955X Memory Controller Hub > 00:01.0 PCI bridge: Intel Corporation 82955X PCI Express Root Port > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition > Audio Controller (rev 01) > 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 > (rev 01) > 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI > Express > Port 5 (rev 01) > 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI > Express PATCH Index: usb-2.6/drivers/usb/core/hub.c =================================================================== --- usb-2.6.orig/drivers/usb/core/hub.c +++ usb-2.6/drivers/usb/core/hub.c @@ -2226,7 +2226,7 @@ hub_port_init (struct usb_hub *hub, stru USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, GET_DESCRIPTOR_BUFSIZE, - (i ? USB_CTRL_GET_TIMEOUT : 1000)); + USB_CTRL_GET_TIMEOUT); switch (buf->bMaxPacketSize0) { case 8: case 16: case 32: case 64: case 255: if (buf->bDescriptorType == --- usb-2.6.orig/drivers/usb/core/hub.c +++ usb-2.6/drivers/usb/core/hub.c @@ -2226,7 +2226,7 @@ hub_port_init (struct usb_hub *hub, stru USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, GET_DESCRIPTOR_BUFSIZE, - (i ? USB_CTRL_GET_TIMEOUT : 1000)); + USB_CTRL_GET_TIMEOUT); switch (buf->bMaxPacketSize0) { case 8: case 16: case 32: case 64: case 255: if (buf->bDescriptorType == Distribution:Debian Unstable Hardware Environment:Dell Precision 300 00:00.0 Host bridge: Intel Corporation 82955X Memory Controller Hub 00:01.0 PCI bridge: Intel Corporation 82955X PCI Express Root Port 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1) 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11) 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01) 05:02.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61)
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.