On Monday 15 January 2007 3:35 am, Phil Endecott wrote: > > Actually this varies from run to run. The most common case is for subtest 2 > to fail; > subtest 12 has failed in just a couple of runs.
Those are the only two calls in that test which go up to userspace. > In most cases it also reports that > the next subtest completed out of order, but not always. That "out of order" thing is puzzling, but would be a different issue. It's clearly a bogus diagnostic, since subcase 12 clearly completed after #11, so it's expected that #13 be next. Further testing on my system turned up more information: - The string fetches done during device enumeration fail sometimes too. This leads to delays, timeouts, resubmissions ... it's not just these cases in test #10. Do you see messages about khubd timeouts when that gadgetfs device enumerates? - In all cases, the control requests which fail don't even get up to userspace. Tracing shows they're received by gadgetfs, and reported. But the kernel never gets asked for those events. As to why they don't get up to userspace, it seems to be something after the kill_fasync() is called which doesn't work. The event loop is never notified; sigwait() never returns, the read on ep0 is never issued. This is outside the realm of gadgetfs infrastructure, unfortunately, so unless a bug turns up in how those notifications are issued I'll suspect something changed in the signal processing triggered by kill_fasync(). I'm thinking of trying to rewrite that userspace loop in terms of poll(), but if that works it would just be papering over a bug elsewhere. Since that uses a different mechanism in the kernel, it's very possible that would work while the kill_fasync() mechanism stays broken. - Dave ------------------------------------------------------------------------- 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
