On Sun, 12 Jun 2005, Adam Kropelin wrote: > These calls did appear when we did hid-core debug, and they're normal. > An UPS typically supports dozens of reports containing everything from > simple boolean flags (on-battery) to line quality (line-voltage, > line-frequency) to environmental data (humidity, temperature). Apcupsd's > algorithm is the following: > > (1) Poll the "interesting" usages. (In Martin's case there are 16 > usages > that qualify as interesting, which translates to 16 control > transfers issued > via hiddev. There is little processing to do on these reports, > so it is not > surprising to see the control transfers issued back-to-back.) > (2) Set internal flags based on current UPS state. > (3) Wait for interrupt reports to arrive. When such a report > arrives, read > its value and go back to step #1. (Note that hid-core filters > out interrupt > reports when the value doesn't change, so apcupsd won't react > until > a report value actually changes.) > (4) If 60 seconds elapse with no interrupt reports, go back to step > #1. > > 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 > Martin's case (based on previous hid-core debug logs) is that the > line-voltage and ups-load reports are fluctuating occasionally. These > changes are delivered via interupt transfers which result in apcupsd > polling the other interesting usages as well.
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. > One thing I can't explain is occasionally I see bursts of control > transfers repeated with no intervening interrupt transfer. That implies > that hiddev is sending events to apcupsd with no reason. In some cases > this happens as many as 20 times in succession, giving the appearance of > a continuous stream of transfers. It's actually a set of 16 transfers > repeated N times because apcupsd thinks an interrupt event has happened. > I need to investigate that behavior. Maybe it would help to debug both the section of hiddev that decides to send events and the receiving code in apcupsd (to see what's in those notifications). Could hiddev be doing this because of some bogus content or faulty decode of the interrupt data? Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
