On Sun, 21 Nov 2010, Robert Pearce wrote: On Sun, 21 Nov 2010, Robert Pearce wrote: > Hi Alan, > > On Sat, 20 Nov 2010 22:45:23 -0500 (EST) you wrote: > > > Now, I should probably say that the "Oxford Vacuum Science" > > > "PicoSphere" (the device with the FT4232) is plugged into a front panel > > > USB socket on a card reader, > > > > This isn't clear. Do you mean that you've got a USB port built into a > > card reader's front panel and the PicoSphere is plugged into that port? > > Yes, that's exactly what I mean. > > > In that case, how is the card reader connected to the computer? > > > It's on one of the internal USB headers - the 2x5 pin header things for front panel sockets. The card reader is a 3.5" drive bay device. So probably there are _two_ connections from the motherboard: one going to the card reader device itself and the other going to the USB port on the card reader's panel. > > > which I suspect means there's a hub in > > > there. And the big blob of usb-storage stuff makes me wonder whether > > > it's actually the card reader that's flaky. > > > > No, there's no hub. The log shows that the high-speed USB host > > controller connected to both the PicoSphere and the storage device (the > > card reader?) stopped working. > > The USB storage device is the card reader; it declares itself as "IN-WIN" and there's no other USB storage present. > > > > > This is not a failure of a peripheral USB device; it's a failure of a > > controller in the computer. An "lspci" listing might be useful, > > together with an "lsusb -v" listing. > > zechariah ~ # lspci > 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge > 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) > 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) > 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) > 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) Okay; the relevant USB controllers are 00:10.3 (EHCI) and 00:10. > zechariah ~ # lsusb -v > > Bus 004 Device 004: ID 0403:8cb0 Future Technology Devices International, Ltd > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0403 Future Technology Devices International, Ltd > idProduct 0x8cb0 > bcdDevice 8.00 > iManufacturer 1 Oxford Vacuum Science > iProduct 2 PicoSphere > iSerial 3 PS09A001 > bNumConfigurations 1 ... > Bus 004 Device 003: ID 10df:0500 In-Win Development, Inc. iAPP CR-e500 Card reader > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 This is odd. The card reader claims to be compliant with the USB-1.1 spec, which did not include high-speed support, and yet your log showed that it was running at high speed. > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x10df In-Win Development, Inc. > idProduct 0x0500 iAPP CR-e500 Card reader > bcdDevice 0.96 > iManufacturer 1 IN-WIN > iProduct 2 iAPP CR-e500 > iSerial 3 0000000001B9 > bNumConfigurations 1 ... > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 9 Hub > bDeviceSubClass 0 Unused > bDeviceProtocol 0 Full speed (or root) hub > bMaxPacketSize0 64 > idVendor 0x1d6b Linux Foundation > idProduct 0x0001 1.1 root hub > bcdDevice 2.06 > iManufacturer 3 Linux 2.6.35.3ovs uhci_hcd > iProduct 2 UHCI Host Controller > iSerial 1 0000:00:10.2 > bNumConfigurations 1 ... This shows that when you run lsusb, the devices were connected to the 00:10.2 UHCI controller on bus 4 and therefore were not running at high speed. Do they return to high speed after a cold boot? > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 9 Hub > bDeviceSubClass 0 Unused > bDeviceProtocol 0 Full speed (or root) hub > bMaxPacketSize0 64 > idVendor 0x1d6b Linux Foundation > idProduct 0x0002 2.0 root hub > bcdDevice 2.06 > iManufacturer 3 Linux 2.6.35.3ovs ehci_hcd > iProduct 2 EHCI Host Controller > iSerial 1 0000:00:10.3 > bNumConfigurations 1 And this shows that the 00:10.3 EHCI controller gets enumerated as bus 1. > (It looks like I was mistaken on the kernel version, it's 2.6.35.3 so a fraction older than I thought) The exact version shouldn't matter much. > The machine in question is one I inherited from my brother, so it's quite old. And he bought it from Time Computers, who don't have a good reputation. It's possible that the EHCI controller on this machine simply isn't working properly any more. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
