On Monday 15 January 2007 9:11 am, Phil Endecott wrote: > David Brownell wrote: > > 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? > > Yes: > > $ grep 'khubd' /var/log/syslog > Jan 15 11:08:52 egypt kernel: usb 4-4: khubd timed out on ep0in len=0/255 > Jan 15 11:22:38 egypt kernel: usb 4-4: khubd timed out on ep0in len=0/255 > Jan 15 11:23:41 egypt kernel: usb 4-4: khubd timed out on ep0in len=0/255 > Jan 15 11:24:53 egypt kernel: usb 4-4: khubd timed out on ep0in len=0/255 > Jan 15 11:27:49 egypt kernel: usb 4-4: khubd timed out on ep0in len=0/255
Not quite what I was seeing, FWIW. > > - 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. > > Do you really mean "kernel" in the last line of that paragraph? Yes; userspace gets notified there's at least one event ready, then asks the kernel (specifically, gadgetfs) for the event data. > IIRC in gadgetfs some events will flush the event queue (e.g. > disconnect I think). Could there be a fault in the code in this area? There may be, but that's a separate issue. > > 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 ... at least the enumeration timeouts are gone; more later ... > > 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. > > When I looked at that code I wondered why it needed any sort of > asynchronous notification at all: can't it just do a normal blocking > read until it gets the next event? Anyway, as you say, changing it > would be papering over. I don't recall all the reasoning right now, but one issue was that signal handling in threaded userspace programs is a PITA one of the good ways to do it is have a thread sitting in sigwait() to collect all async signals (i.e. not SIGFPE, SIGBUS etc which are clearly thread-specific). In this case I simplified things and had that thread be the overall control thread for the (host-visible) device. And "usb.c" was originally a test program, designed more for flexibility than anything else. So having a "main event loop" -- single thread style application model, not pure userspace MT -- could make it easy to evolve in that way. Of course, AIO support kind of blows that model out of the water because the io_getevents() call doesn't play well with poll(), sigwait(), select(), or anything else. :( - 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
