On Sun, 6 Mar 2005, Guennadi Liakhovetski wrote: > Hello all > > Sorry, I haven't been following the USB list(s) for some time, so, maybe > it is all known and discussed multiple times... > > I've got a PCI ALi OHCI / EHCI USB card in my PC, to which I attach a 2.0 > hub, then a 2.0 card-reader and a 1.1 Bluetooth. I guess, it shouldn't be > a problem to mix them like this?
In itself mixing isn't a problem, but see below. > Under 2.6.9, 10 this was failing in > different ways - anyway, if ehci is loaded, bluetooth was non-functional. > From dmesg it looks like if ehci is loaded, it takes the full control over > all devices behind the hub, even over 1.1 ones. If ehci is unloaded, while > ohci is loaded, ohci takes the hub over, re-scans it, takes control over > it. That's right. > I thought, on a 2.0 controller ehci controls high-speed devices, while > the respective 1.1 companion high- and low-speed ones. Or it only works > this way for directly connected devices? Only for directly connected devices. What matters is the speed at which the computer transmits. When the computer is connected to a USB-2.0 hub it will always talk to the hub at high speed, even if there are full- or low-speed devices plugged into the hub. (The hub translates the messages into corresponding lower-speed packets.) Conversely, when a full- or low-speed device is connected directly to the computer, transmission takes place at full or low speed -- otherwise the device wouldn't work -- using the companion controller. > I seem to remember there were > some problems with hubs on 2.0 USB, or was it when connecting 1.1 hub to a > 2.0 port? The problem occurs when a full- or low-speed device plugged into a USB-2.0 hub running at high speed needs to use isochronous transfers. The isochronous translations aren't yet supported very well. > I think, I did have this configuration before - 2.0 hub with mixed 2.0 and > 1.1 devices, but that was a VIA uhci / ehci controller, around 2.6.8 > perhaps? And it did work. It depends on the type of transfers. Only isochronous transfers will cause a problem. And of course, that's what a Bluetooth adapter uses... > Anyway, under 2.6.11, it works, although I still got on Bluetooth plug-in: > > usb 1-6.4: new full speed USB device using ehci_hcd and address 4 > usb 1-6.4: device descriptor read/64, error -32 > usb 1-6.4: device descriptor read/64, error -32 > usb 1-6.4: new full speed USB device using ehci_hcd and address 5 > Bluetooth: HCI USB driver ver 2.8 > usbcore: registered new driver hci_usb > hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb da8b5214 err -12 > hci_usb_isoc_rx_submit: hci0 isoc rx submit failed urb da8b5214 err -12 You can see it right there: the "isoc" submission failed. > But then it seems to work. I guess the driver falls back to a mode that doesn't use isochronous transfers. However I don't know much about Bluetooth USB adapters. > And the card-reader works too! Card readers don't use isochronous transfers. > What still > surprises me is that it says > new full speed USB device using ehci_hcd and address 5 > ^^^^ ^^^^^^^^ > Is it supposed to work this way now? Yep, that's what it's supposed to do. > It does seem to be a good improvement over 2.6.9, 10, anyway! I'm sure that in times to come the mixed-speed isochronous support will improve. It might take a while, though... Alan Stern ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
