On Thu, 2002-01-03 at 14:01, Greg KH wrote: > On Thu, Jan 03, 2002 at 01:46:22PM -0700, Gordon McNutt wrote: > > > > 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. > > uhci has had some bug fixes since 2.4.9 :) >
Ok, so ignore #2. #1 still puzzles me but I'll take whatever works. Unfortunately right now everything I've tried has its own problems ;). > > 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. > > Look at the driver you are using. The generic usb-serial driver doesn't > check to see that the write it sent was NAKed. It just assumes that the > data gets there and goes on. It's a very dumb driver :) > Ok, I can accept that. I wasn't sure if the NAK/resend logic was supposed to be at the class driver level or in the uhci driver. Seems more expensive to put it at the class driver level, but simpler. Whatever. 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. Regards, --gmcnutt > thanks, > > greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
