Re: [linux-usb-devel] Stuck control URBs on some APC UPSes

[Adam Kropelin]

Alan Stern wrote:

On Sun, 12 Jun 2005, Adam Kropelin wrote:

So the basic algorithm means we should expect to see bursts of 16
control transfers once every 60 seconds, plus additional bursts
generated in response to interrupt transfers. What's happening in

That does fit the pattern in the log.  I didn't bother to count the
number of tranfers in each burst so I can't confirm the number 16,
but it would be easy enough to do so.

I did count, and the bursts are always a multiple of 16.

One thing I can't explain is occasionally I see bursts of control

transfers repeated with no intervening interrupt transfer. That implies

send events and the receiving code in apcupsd (to see what's in those

or faulty decode of the interrupt data?

Maybe it would help to debug both the section of hiddev that decides to notifications). Could hiddev be doing this because of some bogus content

--Adam

It certainly could, although in this case hid-core seems to be at fault. The same code path is followed for processing input reports regardless of whether they are a result of interrupt transfers or control transfers. That leads to an interrupt event being delivered to hiddev for control transfers...which is wrong. The problem is mitigated by the fact that reporting to hiddev is supressed if the field value has not changed, which is usually the case. If the field value does change, however, a feedback loop can be formed where apcupsd polls, more events get generated, which leads to more polling. Eventually the feedback loop is broken when the value reads back the same twice in a row. I've attached a rather ugly hack to fix the problem in hid-core. I don't know if this alone will solve Martin's lockup, but I'm hoping it does. Vojtech, this is a fairly gross patch. Do you (or anyone else) have any ideas on how it could be accomplished more cleanly?

hid-nol-hiddev_hid_event-for-control-xfers.patch
Description: Binary data