David Brownell wrote:
>
> Thanks for the info about what 2.5.61 shows ... seems more polite.
> It doesn't seem to be giving you "Unrecoverable Error" (UE) failures,
> unlike the 2.4 "usb-ohci" code. (At least, not without more work!)
>
The (UE) are very rare. 2 out of 100 maybe.
> > <7>usb 5-1: urb ce02e500 usb-00:12.0-1 ep-2-IN cc 5 --> status -110
> > <4>usbfs: USBDEVFS_BULK failed dev 5 ep 0x82 len 4096 ret -110
>
> ... so basically the I/O is timing out on USB. Do you know why?
>
Not a clue. :-(
The timeout to the read is 3 sec.
I've tried everything I can think of to recover form the error,
nothing works short of a power cycle on the part.
The 2.4 urb error code, spit out what looks like, response/request lengths.
Should this be added to 2.5 ?
I saw some strange numbers come out of 2.4
> It'd be rather difficult for that to be a bug in the HCD. This
> would normally be a device problem. "cc 5" means "device not
> responding" (like by an ACK, NAK, or STALL).
>
> > 7. This is what I get when I unplug &replug a part.
>
> What else is going on when you do that? I'd guess it's in the
> middle of some I/O. Does it happen that way if there's no I/O
> going on?
There is NO I/O going on. At least there shouldn't be.
The test is finished, & the system is just sitting there.
>
> > <7>ohci-hcd 00:11.0: bad hash for td ce116180
> > <7>ohci-hcd 00:11.0: bad hash for td ce116200
> > <7>ohci-hcd 00:11.0: bad hash for td ce116040
>
> This is the only thing that suggests issues in the OHCI code.
>
> Each one means the controller handed back a TD that the HCD thinks
> it should have forgotten. Such a disagreement could cause problems
> like the UE interrupts. Do they always happen in threes like that?
>
Always in 3's, I have 11 more that are the same.
> If you can capture a snapshot of /sys/bus/pci/devices/00:11.0/async
It's empty, after I run the test.
> that has the TDs which later get reported with a "bad hash" (the
> high nibble gets morphed), that'd help (but it might be hard to do,
> unless they're a bunch of posted reads).
I'll make a daemon to capture this, but I want to try some other things
first.
>
> > AM I causing the bad hash, because /sbin/hotplug isn't there.
>
> Nope. Haven't had reports about that for many months though;
> it seemed like they were gone.
>
> - Dave
I just rebooted the system.
1.1 parts installed.
loaded usb subsystem.
Ran test.
Port 2 of each controller failed.
Unpluged & repluged ONLY the failed parts.
ALL parts FAILED.
Unplug & replug ALL parts.
All parts pass, & continue to do so.
This almost looks like something isn't getting initialized properly,
and it takes a couple of enumerations to fix itself.
This is just a guess.
--
Gary A. Gorgen | "From ideas to PRODUCTS"
| Tunxis Design Inc.
[EMAIL PROTECTED] | 10470 Pineville Ave. Cupertino, Ca. 95014
| Phone: (408) 973-1542
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
