Alan Stern wrote: Hi Alan, thanks for your comments.
A little, not much. It looks like on the ASRock P67 system, the low-speed device is attached through a hub, probably to a high-speed controller, whereas on the ThinkPad X40 the device is attached directly. The hub itself behaves a little oddly because it doesn't report the connection as low-speed until the port has been enabled. Is this the so-called "rate-matching" hub that Intel is using in their more recent chipsets?
I've had more frequent reports of this problem with recent systems.
That's consistent with the P67's internal hub not working right. Can the user check whether an ordinary USB keyboard (one without an internal hub) works with that computer?
Also, can the user get hold of a USB-2.0 hub and place it between the P67 and the device? Then the Transaction Translator in the external hub would be used instead of the TT in the internal hub.
I'll ask.
Going back through earlier messages in this thread, I see this has already been tried and it works. Also the device works on the P67 if the program resets the interrupt endpoint before each read after the first.
Sorry, there are several different situations, all with similar symptoms. By default the code always does a resetep before each data read on Linux. The device doesn't work without this on Linux on any hardware I know of. There are certainly examples of the same hardware running MSWin not needing resetep's (in fact they fail if resetep's are used). On my test machine, it fails with very similar symptoms to those described by the user with the ASRock P67 if I use an external USB 2.0 hub to connect the device to my system. Once again, the external hub causes no problems when the system is running MSWin. With some hardware running Linux (like the ASRock P67), it doesn't seem to work at all under Linux.
This strongly suggests that the data toggle implementation in the internal hub's TT is broken. An earlier message said that resetting the endpoint fails when an external hub is interposed. Was that a USB-2.0 hub?
Yes.
Does the program work okay with that hub if the endpoint resets are omitted?
On my test system, the device fails to work on Linux without resetep's with or without the USB 2.0 hub present.
The presence of a hub complicates matters, because now we have to worry about toggle settings in the device and in the hub as well as the host. The fact that the transfers work okay on the ThinkPad with no resets indicates that the device does handle its toggles correctly.
We don't know that - the thinkpad was working with a driver that does resetep's before each read. I haven't seen a Linux system work with this device without using a resetep before each read. Only MSWin and OS X systems work without resetep's for this device.
Another earlier message said that Windows and OS X don't have any problems with this device. Were those tests done on the same ASRock P67 machine? (In the OS X case at least, I would expect not.)
No, they were referring to my test machine, an ASUS PK5-V. My OS X machine is a MacBook. Graeme Gill. -- 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
