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