On Thu, 20 Dec 2007, David Brownell wrote: > Alternatively, this could just be sloppy programming that's gotten > by for some time now because in "normal" operation that race isn't > very common. It'd just cause a bit more "background noise" in > terms of flakey products in the field ... hard to say what caused > any given non-reproducible failure.
It's easy to believe this is sloppy programming, like failing to disable interrupts when carrying out a non-atomic operation on a data structure that the interrupt handler also modifies. What's not clear to me is why the problem wouldn't show up on Windows systems at least as often as on Linux systems. The trace shows a time interval between the setup ACK and the following status IN of 9.5 us. (By contrast, the times between the SETUP and DATA or the DATA and ACK were both less than 1 us.) This seems fairly long -- I can't see why Windows should take any longer. Maybe the trace omitted some NAKed packets. > If there are bits with write-zero-to-clear semantics, paranoid > programmers will always write one unless they *intend* to clear. > Likewise with write-one-to-clear: they always write zero unless > they want to clear it on that path. When dealing with hardware, > that type of paranoia is more than just healthy!! Worse yet, the bits may simply be read/write. That would be a believable example of sloppy hardware design. I'm not aware of any way in which the EHCI hardware under Linux can be slowed down. There _is_ a way in which it could be sped up: Set the "park" module parameter for ehci-hcd to something larger than 0. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
