On Sun, 2 Jan 2005, Tilman Schmidt wrote: > > In general, a non-running isochronous pipe shouldn't generate CRC errors. > > From past discussions on this list, I get the impression that -EILSEQ > can also signal a timeout condition.
I just checked the source code, and you're right. The error-codes documentation is incomplete; it should say that -EPROTO can indicate a missing response (i.e., timeout) for an OUT transfer and -EILSEQ can indicate a missing response for an IN transfer. > > For an IN transfer you could expect to see -EPROTO, but various host > > controllers and drivers might report the error differently. For an OUT > > transfer there shouldn't be any errors at all. > > Indeed, the -EILSEQ errors come from the IN transfers. The OUT transfers > are better behaved. That's because isochronous transfers don't have any handshaking. If something goes wrong with an OUT transfer, there's no way for the host to know. With an IN transfer, the host can detect the lack of a response. > > Isochronous pipes don't stall (I think -- the spec is ambiguous). In fact > > they don't have any handshaking capability at all. > > Well, the manufacturer's interface documentation (although I have > learned not to take it too literally) explicitly warns that the > isochronous pipes have always to be fed so that the data stream doesn't > break, because otherwise the pipe would return an error on every > subsequent operation until it was reset. Sounds like stalling to me, > although they never mention the word. I suspect it's different. Stalling means returning a STALL handshake token, something that isochronous pipes don't do. On the other hand, I don't know what the documentation means by "would return an error". > > It sounds like you're doing things right. Maybe the device is > > deliberately generating bad CRCs? > > Would a self-respecting USB device do something like that? ;-) > Anyway, the interface docs don't mention anything of that sort, but > after working on this device for a year nothing surprises me much > anymore. How could I find out? You can't. But after checking the driver source, I believe that what's happening is not bad CRCs but simply a missing response. Not surprising, considering this happens when the pipe has been turned off. So the problem you face is determining whether -EILSEQ indicates a genuine CRC error or a missing response. In the end maybe it doesn't matter very much -- either way you failed to receive the data. You'll just have to figure out how, and under which circumstances, you want to report the error to the user. Alan Stern ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
