On Sat, 1 Jan 2005, Tilman Schmidt wrote: > Working on a driver for an ISDN device[1] designed to transfer the > actual B channel data of an established ISDN connection over a pair of > isochronous pipes, one for each direction. > > I am setting these up by first submitting three URBs for each pipe, > before sending the command for actually establishing the B channel > connection to the devide over the default control pipe. Conversely, I > unlink the URBs after the device has signalled the connection to be closed. > > Annoyingly, this results in a couple of EILSEQ errors being signalled > every time a connection is started or terminated. My guess is that this > is caused by the isochronous pipe not running yet/anymore. I don't know > why this should cause a CRC error, but as there are several reports in > the list archives that EILSEQ can result from many other causes than the > official "CRC error", I guess it's just another one of those.
Which host controller driver are you using? In general, a non-running isochronous pipe shouldn't generate CRC errors. 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. > As this is generating a lot of questions from users, I would like to > avoid these error messages, but I don't see how. If I send the connect > command before submitting the URBs I fear the isochronous pipe might > stall if I am not quick enough, and on closing the connection I do not > even have that option, because the connection can be closed at any time > by the other party. Isochronous pipes don't stall (I think -- the spec is ambiguous). In fact they don't have any handshaking capability at all. > What is the supposed sequence of actions for setting up and tearing down > isochronous pipes? Are these EILSEQ errors unavoidable? Should I just > ignore them, and if so, how do I distinguish them from serious ones > which might also occur - such as actual CRC errors? It sounds like you're doing things right. Maybe the device is deliberately generating bad CRCs? 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 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
