It is because it is hard to generate an error in testing two simultaneously. When testing simultaneously, much time is required by the time it generates an error.
This is basically a good thing: the root causes are getting fixed one by one, so it needs more time before one of the remaining problems appears.
Of course, that means it's harder to find/fix whatever problem you're hitting ... :(
The reason is not known.
Haruo> 1. Bulk command transfer result=-104
[skip]
Alan> This was the same sort of pattern we saw before. No data was Alan> transferred from the drive, and the command timed out
> and was aborted.
I am also looking at this pattern repeatedly.
Some sort of USB-level trace would be very useful here, such as from a CATC capture.
It seems that a device does not answer in the case of kernel 2.4.
However, when operating by kernel 2.6 and two or more devices
are connected simultaneously, it operates. I cannot think the error of a device.
I'd almost agree, except that the device stops responding; and seems to stop responding to anything except (cases I've seen) that it'll accept more OUT packets ... maybe treating them as data to write to the disk (one hypothesis).
When a device stops responding, it's hard to think the problem is anything other than with the device. (Though I still don't see where the storage class-specific reset gets sent by usb-storage, maybe that'd clean up better.)
What's curious is that "two or more devices connected" behavior. Are they both doing I/O at the same time? Having a second active device would change a few things:
- The EHCI controller will switch between endpoints, doing some transfers from one device then the next.
A second active device means longer gaps between packets going to the device ... so if one of those devices can't handle continuous streaming of high speed packets, it may lock up except when that second device increases those gaps.
Yes, we DO seem to have started seeing such storage adapters. Ones from GeneSys appear to have that problem with fast EHCI controllers, like the one in NForce2 (which can issue two or more back-to-back transfers using the "park" mechanism).
- Since usb-storage on 2.4 doesn't stream usb-storage transfers (64 writes of one page, vs one big write of 64 pages), the EHCI controller spends lots of time unlinking bulk endpoints (QHs) from its i/o queue and linking them right back again.
The VIA chips have been very sensitive, even buggy, in how they handle this logic. I've been unable to convince myself the current EHCI driver has a bug in this area -- though maybe it's possible someone else would have better luck finding one.
If this is a factor, then you should be able to change the behavior by increasing EHCI_SHRINK_JIFFIES (top of ehci-hcd.c), maybe to HZ/100 or so. I know that increasing that from zero was a big win in some VT6202 (stability) and VT8235 (performance on 2.4) testing, but the other EHCI silicon didn't much care.
That's about all the insight I have to share on this at the moment.
- Dave
------------------------------------------------------- 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
