[linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects

Antti P Miettinen ananaza at iki.fi
Sun Mar 4 22:42:07 CET 2007

Chris Johns <chris at contemporary.net.au> 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


Pete Zaitcev <zaitcev at redhat.com> 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


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

[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.


More information about the linux-dvb mailing list