On Thu, 2002-01-03 at 10:29, Greg KH wrote: > On Wed, Jan 02, 2002 at 07:13:26PM -0700, Gordon McNutt wrote: > > Looks like DATA OUT toggling on BULK endpoints has a bug > > <snip> > > > >>>>>>> DESCRIPTION <<<<<<< > > > > This is 100% reproducible, but I'm using an experimental device. The > > special property of this device is that it *always* NAKs packets sent > > to one of its bulk endpoints (at least it should, but more on that > > later...). > > > > I load a usbserial module built for generic support and give it the > > product and vendor to recognize my device. On cable attachment > > enumeration proceeds as expected and /dev/ttyUSB0 becomes my device. > > I start a CATC trace and on the host: > > > > $ echo hello > /dev/ttyUSB0 > > > > As expected, the echo command blocks. After a second or two I kill it > > with two Ctrl-C's from the keyboard (for some reason, one is not enough). > > The CATC trace shows all the DATA OUT packets containing the data are > > NAKd, as expected. The data toggle is 0 for all these packets, as > > expected. > > > > Now repeat the process. This time, the echo command returns immediately. > > The CATC trace shows that the DATA OUT toggle bit is now set to 1. The > > device ACKd the packet. > > > > My theory is that the device hardware sees the data toggle of 1 and > > mistakenly believes the host lost an ACK and is resending a packet. So > > the device ACKs the packet (and probably just discards the data). I'm > > not sure how else device hardware can accomodate lost ACKs, so I guess > > this is sane behaviour on the part of the device. > > > > If so, then this is probably a bug in the Linux UHCI driver. If I > > understand the spec correctly, the host should not advance the toggle bit > > unless the packet was ACKd. > > > > I've poked around in the code a bit, and I see a couple of places in > > uhci.c where the toggle bit is being messed with, but I'm not sure > > how my signaling the process is removing the urb. It seems that at > > that point the toggle sequence associated with the urb needs to be > > canceled unless it was ACKed by the device. > > > > I don't mean to be impolite, but I do not subscribe to this list. So please > > CC replies to [EMAIL PROTECTED] >
I'm now subscribed so ignore that statement. > First off, does this also happen with the other UHCI driver (not the > "Alternate" one?) > Well, now I'm baffled. 1. I could not repeat the experiment with uhci 2.4.17 (which I thought I did yesterday). Instead, the device now *never* responds to the DATA OUT packets -- wether I've enabled the h/w to respond or not. This is puzzling because the CATC shows the packets look OK, and replacing uhci with usb-uhci does not give this symptom (see 3 below). 2. Using uhci with 2.4.9 I can still get the symptoms described in my first mail. 3. Using usb-uhci with 2.4.17 I now see the following problem which looks related. If I do the echo command twice in a row here's a summary of what my CATC shows (the second column shows the toggle bit): #1: OUT 0 'hello' ... ACK #2: OUT 1 '\r' ... NAK #3: OUT 0 'hello' ... ACK #4: OUT 1 '\r' ... ACK The NAK on #2 is probably due to the peripheral's driver not enabling the h/w because it's still working on #1. I would expect the host to continue resending it until the device ACKs it or a timeout occurs, but it only makes the one attempt. Since the peripheral does not ACK #2 I would expect the toggle bit to remain at 1. But since the host advances the toggle bit the peripheral thinks #3 is a resend of #1 so it ACKs it but does not interrupt the peripheral device driver. It essentially just drops the packet. #4 is normal, but the peripheral has effectively lost #2 and #3 and its driver will never know it. > When you cancel the "echo" command the urb that has been submitted to > the device is canceled. So the host controller driver thinks it is > finished. > > Then when you repeat the "echo" command, a completely new urb is > created and submitted to the device. Since the transmission is a new > one, I'm guessing that the host controller driver thinks it is ok to > toggle the data toggle bit. > > As for if this is really a bug or not, I'll leave that to the host > controller driver authors :) > > thanks, > > greg k-h Regards, --gmcnutt _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
