Chris Johns <chris@xxxxxxxxxxxxxxxxxxx> writes: > localhost kernel: urb completition error -32. > localhost kernel: urb completition error -71. > localhost last message repeated 347 times > localhost kernel: usb 8-1: USB disconnect, address 2 Hmm.. any comment to http://article.gmane.org/gmane.linux.usb.devel/51482 Pete Zaitcev <zaitcev@xxxxxxxxxx> writes: > -32 is a STALL condition. > [..] > In storage world, we must clear stalls. In your trace there was no > attempt to clear anything, just next transfer resubmitted. But perhaps > it's all right for your class and/or protocol. i.e. should there be handling for EPIPE in usb_urb_complete() in usb_urb.c to clear stalls? The current code looks like it would behave pretty much like the "last message repeated 347 times" suggests :-) I tried to add halt clearing upon EPIPE but it seems that it does not cure the disconnects. I put a diff at http://brigitte.dna.fi/~apm/t500-stall-clear.diff in case someone wants to take a look. I strongly recommend against blindly applying the diff - just look at it and do the right thing :) It seems that EPIPEs do not exactly match with transaction errors, for example: [17180472.536000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=80004d08 [17180517.620000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=00008d08 [17180518.728000] ehci_hcd 0000:03:0c.2: XactErr, ep2in, token=00004d08 [17180563.796000] pipe -1073642880 needs clearing [17180563.796000] scheduling halt clear for pipe -1073642880 [17180563.796000] clearing halt for pipe -1073642880 [..] There are transaction errors which do not seem to be visible to the urb completion handler but some are. It seems that the halt clear sometimes avoids a disconnect for the transaction error with transfer length 56: [17180240.736000] ehci_hcd 0000:03:0c.2: XactErr, ep3in, token=8038c948 [17180240.736000] scheduling halt clear for pipe -1073642880 [17180240.736000] clearing halt for pipe -1073642880 [..] But apparently sometimes the halt clear does not seem to manage to interfere in time (?): [17182220.876000] ehci_hcd 0000:03:0c.2: XactErr, ep3in, token=8038c948 [17182220.876000] pipe -1073642880 needs clearing [17182220.876000] scheduling halt clear for pipe -1073642880 [17182220.876000] ehci_hcd 0000:03:0c.2: XactErr, ep0out, token=80008148 [17182220.876000] ehci_hcd 0000:03:0c.2: devpath 1 ep0out 3strikes,t=80008148 The transaction error is for EP 3, we manage to schedule the halt clear but the hard failure happens for EP 0. Hmm.. where are the control urbs sent.. maybe I'll look into adding halt clearing for those too.. But I suppose the right solution would be to get rid of those transaction errors in the first place. By the way - the firmware definitely seems to affect transaction error frequency for me. When running with the 01 version, I had my first transaction error after two days of uptime (no hard failure). With the 02 rc2 firmware I start getting transaction errors withing minutes from boot and hard failure usually happens within an hour. -- http://www.iki.fi/~ananaza/ _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
