On Friday 19 January 2007 1:30 pm, Alan Stern wrote: > On Fri, 19 Jan 2007, David Brownell wrote: > > > On Friday 19 January 2007 9:17 am, Jon Smirl wrote: > > > > > There is still the unexplained case of it working ok when plugged into > > > a hub, it only fails on a root controller. But it failed on both ICH4 > > > and ICH5. It works on both my USB 1.0 and USB 2.0 hubs. > > > > Sorry if this came out in earlier discussion ... but has it been > > established that this isn't a UHCI-specific issue? Assuming this > > is a full-speed device, did you test with OHCI root hubs? > > I think it unlikely that this is UHCI-specific, but it's always a good > idea to make certain...
Exactly. > > I'd be rather suspicious about the conclusion that this is a bug > > in the peripheral device hardware: > > > > - It works through external hubs. So not working through a root hub > > strongly suggests it's a bug in that root hub ... and if it fails > > on OHCI too, I'd be more likely to suspect the same bug in both > > root hub drivers. > > Hmmm... Don't try to have it both ways. I'm not. The preponderance of evidence suggests the device is OK; which means that if it doesn't behave on root hubs, those root hubs deserve some very careful going-over. > If OHCI succeeds you conclude > it's a bug in uhci-hcd; if OHCI fails you conclude it's a common bug in > both uhci-hcd and ohci-hcd. If anything I would suspect a hardware bug in > the Intel controllers -- which would be supported if the device worked > with OHCI. On the other hand, if the device also fails with OHCI then I'd > be even more inclined to believe the device is buggy. Except ... that it worked through external hubs. Which to me delivers a huge suggestion that it's not a buggy device, especially in conjunction with the other points (below). > And as a matter of fact, I'm not so sure that the device really does work > correctly with external hubs. It may _appear_ to work, but that could > simply be the result of other factors kicking in. At one point Jon sent > me (it was large enough that he didn't want to post it to the entire > mailing list) a log showing the what happened when the audio device was > attached to an external hub. The log showed that at regular 30-second > intervals, something was waking up every USB device -- possibly some > daemon periodically doing the equivalent of lsusb. Each time this > happened the audio device's resume failed because it disconnected from > its hub and then reconnected. That is pretty much the same as what we > see with a root hub. > > The log also showed some instances where the audio device did resume > successfully while attached to a root hub. This is further evidence of some bug in the driver stack that doesn't show up on all paths. Maybe the delay after resume isn't long enough, or something. > > - This autosuspend mechanism is still very new, and of a complexity > > where I'd expect it to trigger problems in the driver stack. > > On the other hand, it works correctly for many other devices. Not incompatible with the other points I've made. It's complex, which means LOTS of event sequences that "real world" usage will be triggering. If we assume only one hundred distinct event sequences to be tested, it'll be hard to come up with a formal test profile covering all of them. Assume a really good test profile, covering 90% ... that's still quite a lot of cases that will appear in the field but not "in the lab". > > - This class of hardware bug would be surprising to me, considering > > that devices routinely suspend then resume in the middle of their > > enumeration sequences. > > They _reset_ then resume, which isn't quite the same thing, although it > is similar. Note that the audio device does enumerate correctly > initially. Right, so it's likely there's something else going on. Fiding it may be quite the puzzle though, especially without a CATC type trace. > > - Hey, it was intermittent even on Alan's UHCI system, which is also > > a symptom of a bug in a code path that's not always traversed. > > No, that was something else. The intermittent events I was talking about > were definite hardware bugs which left a uniquely identifiable fingerprint > in the system log. They aren't the source of Jon's problem (although that > bug _did_ occur in at least one of the logs, but it was for a device on a > different port, not the audio device). > > > Combining all that makes me more suspicions that this is just an > > issue with the current iteration of the Linux support. Some host > > side driver misbehaving, rather than the peripheral hardware or > > firmware. > > Sometimes it can be very difficult to tell exactly where a problem lies. No kidding ... ;) - Dave > Alan Stern > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
