> > > > 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.
I was talking about transactions, not packets. Let me give you a quick example to make sure we're talking about the same thing: luvcview-error-32-on-set-cur: The failed SetCur at 7.126 has 479 microseconds between the SETUP transaction and the OUT transaction (with plenty of PINGs in between). The successful SetCur right before it, at 7.104, has 866 microseconds between the same transactions (with more PINGs in between). What controls this difference in timing? From my understanding of the earlier messages in this thread, this is the EHCI controller and cannot directly be influenced by the kernel, right? > > > 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". But you're talking about NAKs here, whereas the control requests in questions only shows PINGs that are responded with ACKs. > After a quick look, I didn't notice any particular difference in timing of > the control transfers under Linux and under Windows. If you look at the same delay between SETUP and OUT _transactions_, you'll see that under Windows it takes longer than 500 microseconds, sometimes even more than a millisecond. > Exactly what are the conditions under which you expect the device to mess > up the protocol? I'm not sure I understand your question. What do you mean by "mess up the protocol"? Cheers, Martin ------------------------------------------------------------------------- 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
