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