I'd appreciate some advice from anyone here who's familiar with using signal-based notification (setting urb->signr) when using usbfs. It's working correctly when this particular device is on, as well as when it's disconnected, but I'm seeing what seems to be odd behaviour when the device is connected but off. Since querying the configuration and claiming the intterface both work, the code goes ahead and tries to do I/O. The URB for expecting input is submitted, the signal arrives, but the non-blocking reap fails with EAGAIN. I tried a blocking reap, which ended up waiting forever. My question, therefore, is: Under what circumstances should usbfs code, after having received a signal, expect to not be able to reap a URB, and how should it interpret this situation? In case it matters: It's an interrupt input endpoint. The error indicated by the signal (siginfo->si_errno) is -ENOENT, which, as I see it, does make sense because, with the device connected but off, it could mean that the USB descriptors are available but that the endpoints can't actually be used. In this situation, though, wouldn't the URB still be reapable with its status set to -ENOENT? I see the following code in drivers/usb/core/devio.c, that does seem to be doing some kind of urb cancellation: 518: if (as->status < 0 && as->bulk_addr && as->status != -ECONNRESET && 519: as->status != -ENOENT) 520: cancel_bulk_urbs(ps, as->bulk_addr); Whatever this code is for, it looks like it's specifically not being executed if the error is -ENOENT. -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: dave@xxxxxxxxx | Canada K2A 1H7 | http://FamilyRadio.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
