On Wednesday 07 June 2006 11:50 am, Alan Stern wrote: > On Wed, 7 Jun 2006, Vivek Dharmadhikari wrote: > > > Alan > > > > Here are the results again. > > > > The few transactions for the time period before the "command_abort called" > > are typically like below > > > > 1. Host sends 512 bytes OUT packet which is ACKED. > > 2. Host sends 13 bytes IN packet which is ACKED. > > 3. Host sends 31 bytes OUT packet which is NYETD.
So the peripheral accepted the data (didn't NAK), but still isn't quite ready for the next data packet (NYET has sort of an implicit ACK) ... host must PING until it gets an ACK. > > 4. Host sends PING packet which is ACKED. > > 5. Repeat of sequence 1-4 > > You haven't parsed this quite right. The interval between successive > commands occurs between your steps 3 and 4. So the correct sequence is > this: 31 bytes OUT (NYET, PING, ACK), 512 bytes OUT (ACK), 13 bytes IN > (ACK), and repeat. Well, the OUT can get a NYET, in which case host can PING for a while until it gets an ACK, then it issue the next OUT getting ACK not NYET. That can be true for any bulk OUT transfer. (The point of the protocol being that senting a 512 byte packet that will be NAKed is a waste of bandwidth. So instead of sending NAK, the peripheral can send NYET to kick in the mode where PING is used for a while, polling without any need to send data that will be ignored.) Section 8.5.2 in the usb spec. > Note also that from the host's point of view, the 31-byte OUT URB > completes when the NYET packet is received, Right ... implicit ACK. > So what happens is that usb-storage submits the 512-byte OUT URB, but the > endpoint is in a NYET state and for some reason the host controller is not > stimulated to send a PING packet. Therefore the data transfer never gets > started, and 30 second later it times out. I don't see this happening ... it's not supposed to, and I just looked at how the bits affecting PING are managed in the EHCI driver to verify that it seems to be coded right. > It might give you a hint as to where to start looking in > the ehci-hcd driver: where a new URB is added to an empty bulk-OUT queue. Not quite as simple as that, unfortunately. The OUT endpoint finishes its 31 byte tx, then becomes a candidate for removal from the async schedule; meanwhile it sits there, the controller may be reading the QH. So in the typical case this is a _live_ endpoint update ... or it could be getting added to an endpoint that's in the process of being descheduled, or which has finished being descheduled. Whose EHCI silicon was this? I know that some of the older silicon, which implements the EHCI 0.95 spec, has what would be called bugs in 1.0 silicon which affect this behavior. Specifically, an empty QH in the schedule will sometimes spontaneously exit the "wait for new URB" mode and enter a mode which isn't even supposed to exist. It's possible that the workaround for that family of bugs has an issue in this area, specifically when PING applies along with all the other tricky races. That might actually match some of the behavior seen ... that bogus mode would have a dummy QTD in the QH overlay, so the QTD for that new URB would never become active. - Dave _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
