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 :) > 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 :) thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
