search for: dstate_poll_fd

Hello gents, while getting rid of gettimeofday, I've spotted something I'd like to discuss in implementation of socket polling in driver/main.c::main and driver/dstate.c::dstate_poll_fds My observations follow: 1/ I'm not very happy with the poll mechanism design as whole. I mean, typically, you implement the poll as { poll(); process(); }* loop; in pseudo-code: shut_down = false; fd_set.init(...); timeout.set(...); while (!shut_down) { status = poll(fd_set, timeout)...

2011/2/15 Lupe Christoph > On Monday, 2011-02-14 at 21:54:20 -0000, Arnaud Quette wrote: > > I definitely need more info! > > please reply to ALL: > > > - what is the exact model and date of manufacturing? > > SmartUPS 300I NET. I have the serial number (GS9809283199) but no date. > it seems to be a recent model. > - are you sure this unit is ok? > >

2011/2/15 Lupe Christoph > On Monday, 2011-02-14 at 21:54:20 -0000, Arnaud Quette wrote: > > I definitely need more info! > > please reply to ALL: > > > - what is the exact model and date of manufacturing? > > SmartUPS 300I NET. I have the serial number (GS9809283199) but no date. > it seems to be a recent model. > - are you sure this unit is ok? > >

Gentlemen, As reported earlier, my UPS burps a lot of unsolicited interrupt messages. I have made some experiments with the UPS using newhidups directly, and noticed that the poll frequency of the dstate_poll_fds() calls in main.c can be heavily skewed by the timeout provided in the libusb_get_interrupt() call in libhid.c (currently 5 sec!). For a UPS that provides few interrupt messages, this may result in a behavior equivalent to a pollinterval of 5 or more for any pollinterval settings of less than 5....

...ary.PresentStatus.NeedReplacement UPS.PowerSummary.PresentStatus.OverLoad Note that these are all events that appear through HIDGetEvents() in upsdrv_updateinfo(), and all relevant elements are updated there. Here is my puzzlement: If I run with the default poll_interval (which first applies to dstate_poll_fds(), but indirectly also controls the upsdrv_updateinfo() frequency), there are updates roughly every 2 sec, as expected, and the three forms seem to cycle like this: (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (1) (2) (3) ... which has the effect that I might not get a status change for close...

I was doing some testing with the 2.6.0-1 beta Windows installer and a Cyber Power CP1350PFCLCD UPS, and ran into an infinite loop in the usbhid-ups driver if the UPS is lost on the UPS bus. This is on a Windows XP SP3 system. USB device access is via libusb 1.2.4.0 (driver mode, not filter) in case that matters. Everything seems to work just fine so far while the UPS is connected (so kudos,

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -