On Fri, Jan 04, 2002, Gordon McNutt <[EMAIL PROTECTED]> wrote:
> On Fri, 2002-01-04 at 11:44, Johannes Erdfelt wrote:
> > On Thu, Jan 03, 2002, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jan 03, 2002 at 02:08:58PM -0700, Gordon McNutt wrote:
> > > > 
> > > > However, I'm convinced that the toggle bit should be advanced if and
> > > > only if the packet was ACKd. Advancing it on a NAK seems to defeat the
> > > > whole purpose of the toggle mechanism as a means of keeping the host and
> > > > peripheral in synch.
> > > 
> > > I think you are correct.  According to the USB spec, in section 8.6 it
> > > says:
> > >   Transmitter sequence bits toggle only when the data transmitter
> > >   receives a valid ACK handshake.
> > > 
> > > So it looks like a bug in the host controller driver.  Does the same
> > > thing happen for usb-uhci.o or usb-ohci.o?
> > 
> > Sorry for the delayed reponse.
> > 
> > This is highly unlikely. The way UHCI works, you pre setup the data
> > toggle in the TD's and the UHCI controller does the rest.
> > 
> > It does not advance to the next TD if it receives a NAK.
> > 
> > For what you described to happen, usb-uhci.c would need to scan the
> > TD's, find the TD which is being NAK'd and then retoggle that TD and all
> > of the following TD's, which is something that just doesn't happen by
> > accident and would be very difficult since we don't get interrupts on
> > NAK's.
> > 
> 
> In my example there is likely only one TD for this URB. It isn't
> subsequent TDs from the same URB with bad toggle bits, it's the first TD
> for the next URB.
> 
> I haven't looked too closely, but is this scenario possible:
> 
> When usb-uhci.c builds out the TD chain, it picks the first toggle bit
> for the first TD based on what is stored as the last toggle for that
> endpoint for that device. Correct so far?
> 
> If so, then at which point does usb-uhci advance the toggle bit for the
> device's endpoint so that the next URB TD chain can be setup correctly?
> If it only does it on receipt of an ACK then I see your point. But if it
> does it under any other circumstance then that is probably where the
> problem occurs.

When the URB is finished, it'll go through all of the TD's and set the
next toggle appropriately for the last TD that was finished.

In this case, there may be a bug, but it's pretty well tested under
usb-uhci.c atleast. I think uhci.c may have a bug hidden there.

> > Do you have a CATC trace that we can take a look at?
> 
> I'll need to switch kernels so I'll post one later. Do you want the raw
> trace file?

Yes please.

JE


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to