On Wed, 4 Oct 2006 [EMAIL PROTECTED] wrote: > Hey Alan, > > Thanks a lot for looking at the traces! > > > > What's interesting to see is that for most failed requests the first > data > > > transaction follows within less than 500 microseconds after the SETUP > > > transaction. It's not always the case, but it definitely seems to help > > > trigger the problem. > > > > The same thing is true for most of the successful transfers as well, so > > I'm not sure what to make of it. > > If I compare the stalled GetMin requests to the successful ones, it seems > that the successful ones take longer (generally more than 1 ms). Can you > point me to some successful requests where the time difference is less than > 500 us?
In ALL of the control transfers that I looked at, the time difference between the SETUP packet and the first IN or OUT packet was never more than 5 or 6 microseconds. The time difference between the ACK of the SETUP and the first IN/OUT is around 2 or 3 microseconds. That's true for the Windows trace as well. Which makes sense. That's what you would expect: the host controller issues the first data transaction as soon as the setup transaction has completed successfully. > > Incidentally, the trace shows that quite often the device responding to > > PING with ACK even though it's not ready to accept any data. That > happens > > lots and lots of times. It looks like another bug. > > We're aware of that, although we don't think it's a bug. From what I've > been told (I haven't done any research on that myself), the USB > specification does not say anything about this. Although it's admittedly a > little odd, that by itself does not cause any problems and the behavior on > Windows is the same. Quoting from the USB 2.0 spec: --------------------------------------------------------------------- 8.5.1.1 NAK Responses to OUT/DATA During PING Protocol The endpoint may also respond to the OUT/DATA transaction with a NAK handshake. This means that the endpoint did not accept the data and does not have space for a wMaxPacketSize data payload at this time. The host controller must return to using a PING token until the endpoint indicates it has space. A NAK response is expected to be an unusual occurrence. A high-speed bulk/control endpoint must specify its maximum NAK rate in its endpoint descriptor. The endpoint is allowed to NAK at most one time each bInterval period. A NAK suggests that the endpoint responded to a previous OUT or PING with an inappropriate handshake, or that the endpoint transitioned into a state where it (temporarily) could not accept data. An endpoint can use a bInterval of zero to indicate that it never NAKs. An endpoint must always be able to accept a PING from the host, even if it never NAKs. --------------------------------------------------------------------- I'd say you just barely squeak by. If there were an endpoint descriptor for endpoint 0, the device's NAK rate would certainly the descriptor's limit, since the maximum allowed rate is 1 NAK per microframe. In any case it's clear that the device's behavior doesn't comply with the intent of the spec; it's not an "unusual occurrence". > > The real question is why does the device work under Windows. To answer > > that will require looking at traces made with a Windows host. > > That's indeed what we're trying to find out. I've uploaded a Windows trace > to the FTP server. It covers plugging of the device, streaming, and setting > parameters like brightness, pretty much the same thing that leads to > stalled requests on Linux. After a quick look, I didn't notice any particular difference in timing of the control transfers under Linux and under Windows. Exactly what are the conditions under which you expect the device to mess up the protocol? Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
