On Sat, 6 Feb 2010, Alan Stern wrote: > On Sat, 6 Feb 2010, David Fries wrote: > > > I have a UPS plugged into USB being monitored by apcupsd, and once and > > a while a control in transfer is submitted which isn't completed. > > When not completed the usbhid control request queue fills up until no > > more control requests can be submitted (not that any of the previous > > ones are being serviced), preventing the UPS from being monitored. > > > > As the control request doesn't complete the hid-core.c hid_ctrl > > completion handler doesn't get called, and things stop there. Further > > control requests to the hid-core pile up in the queue until the queue > > is filled up, then it complains for each new request. The only way > > out is to kill apcupsd (and wait for it exit), then reload the > > ohci_hcd module with the stock 2.6.31 kernel. I've included a debug > > patch that will kill the urb when the queue is nearly full and > > resubmit it. While it does work, I don't consider this the right > > solution and it still leaves the UPS unmonitored for the nearly hour > > that it takes the control queue to fill up and trigger my routine. The > > usb monitor doesn't say why the control request doesn't complete, just > > that it was submitted and didn't complete. > > > > Any ideas? I can try changes or enable other debugging, just keep in > > mind the time for this to reproduce, which could be a week or a month > > between stuck control requests. > > Really, the only valid reason for a control request not to complete in > a timely fashion is that the device refuses to accept or acknowledge > it. In your case the device must be NAKing the status stage of the > control-IN transfer, since a data packet was received. It's also > possible (but rather unlikely) that the USB hardware in your computer > is malfunctioning. > > At any rate, the proper fix is for the submitting program (acupsd?) > to include a proper timeout, maybe on the order of 10 seconds, when > submitting the control URB. Sorry, I missed the fact that these control URBs are being submitted on your behalf by the usbhid driver. This means that the proper solution is for usbhid to use a kernel timer to cancel control URBs that take too long. I don't know how long the timeout should be; it must vary with the device. Probably somewhere between 10 seconds and 1 minute, but the HID maintainer is the person to ask (CC'ed). Alan Stern -- 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
