similar to: [Alioth] SSH keys removed

Since reports received over the interrupt pipeline are a recurring problem for various types of UPS'es, I propose to simply ignore the data we receive there and only flush the respective report buffer. By doing so, at the time the interrupt reports are processed the first variable that is retreived will trigger a poll for the corresponding feature report and we should be fine. The impact on

Citeren Arnaud Quette <aquette at alioth.debian.org>: > Author: aquette > Date: Mon May 18 12:14:54 2009 > New Revision: 1846 > > Log: > Enable timestamp on output messages (format "%H:%M:%S: msg") I think this should only be done for messages that are sent to stderr. In most cases, syslog will already prepend a timestamp, so this is probably redundant.

> - drivers/dstate-hal.[ch]: added sleep here, to limit the polling rate > (previously, the driver would completely ignore the poll interval and > would run upsdrv_updateinfo() without any delay in between) > > The changes to dstate-hal.[ch] should probably be backported to Testing > ASAP, since ignoring the poll_interval is not a good idea (you'll be > basically polling

> Author: adkorte-guest > Date: Mon Jun 25 19:26:09 2007 > New Revision: 988 > > Log: > Update to reflect changes in the way we deal with dstate_dataok() and > dstate_datastale(). > > Historically it was needed to call dstate_dataok() regularly, to prevent > staleness warnings. This is no longer needed, now the server will PING > drivers it has not heard of

THANKS, but the 'megatec' driver only works whith windows OS via USB, and i need it for red hat OS with USB-serial connection... Please, anybody can help me.... nut-upsuser-request@lists.alioth.debian.org escribi?: Send Nut-upsuser mailing list submissions to nut-upsuser@lists.alioth.debian.org To subscribe or unsubscribe via the World Wide Web, visit

> Feature Requests item #310492, was opened at 07/01/2008 09:57 > Status: Open > Priority: 3 > Submitted By: Arnaud Quette (aquette) > Assigned to: Nobody (None) > Summary: Allow to specify hostnames in ACL (upsd.conf) > Category: None > Group: None > > > Initial Comment: > allow a new ACL form: > ACL hostname/mask > > example: > ACL localhost

Citeren Arnaud Quette <aquette op alioth.debian.org>: > Modified: trunk/drivers/tripplite-hid.c > ============================================================================== > --- trunk/drivers/tripplite-hid.c (original) > +++ trunk/drivers/tripplite-hid.c Sun Mar 1 19:56:31 2009 > @@ -84,6 +84,8 @@ > > /* HP R/T 2200 INTL (like SMART2200RMXL2U) */ > {

Alexey, I posted this before, but never got a reply. So I'm reposting this again. In the present HID PDC implementation by PowerCOM, expect problems with the non-compliant implementation of the DelayBeforeShutdown and DelayBeforeStartup pages. Third party applications will expect that these follow the HID PDC specifications if you name them like this (and break terribly in the

An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080225/377bed98/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: usbhid-ups.loghid-ups.log.D4.zip Type: application/zip Size: 5428 bytes Desc: not available Url :

> +22 = Gamatronic UPSs with alarm interface > + [CP=RTS] [OL=CTS] [LB=\-DCD] [SD=DTR] > + > +22 = CyberPower SL seriess > + [CP=RTS] [OL=CTS] [LB=\-CAR] [SD=DTR] > + > + This part of the patch is no good. While TIOCM_CAR is equivalent to TIOCM_CD (at least in some implementations) CAR certainly isn't handled the same as DCD by genericups. It won't be

Browsing through the newhidups.c code, I stumbled across the following: /* master list of avaiable subdrivers */ static subdriver_t *subdriver_list[] = { #ifndef SHUT_MODE &generic_subdriver, #endif &mge_subdriver, #ifndef SHUT_MODE &apc_subdriver, &belkin_subdriver, &tripplite_subdriver, NULL #endif }; Shouldn't the 'NULL' terminator be outside the

Looking for ioctl() calls in the drivers, I noticed that the energizerups.c code looks a lot like a megatec protocol over a USB connection. It uses 8 bytes per packet, which makes it look like the agiler subdriver in megatec_usb. Do we know if there are people that use this driver now and that might be able to verify this? Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66

> Author: agordeev-guest > Date: Wed Oct 3 00:09:21 2007 > New Revision: 1136 > > Log: > - drivers/megatec_usb.c: added ability to do subdriver-specific > initialization, and moved some shared code to agiler init function > since krauler doesn't need it. [...] I'm not very thrilled about this patch: 1) Down at the subdriver level, one shouldn't use

I want to revive an old discussion. Should we use the contents of input reports or not? A while back, we decided not to use the contents of input reports, because there is no guarantee that input report 'n' has the same meaning as feature report 'n'. We have not seen any cases so far where this is not the case, but as far as we could see, there is nothing in the HID PDC

Arnaud, I have a question regarding the below structure you've added: > typedef struct usb_device_id_t { > int vendorID; > int productID; > void*(*fun)(); /* handler for specific processing */ > } usb_device_id; I don't understand the last element in this structure. While there can be plenty of reasons for functions returning (void *), I can't figure out what

Hi, I tried in vain to find an answer for my question, so let's post it here. I've got a seemingly perfectly well running setup with NUT and a APC SmartUPS 750. However, my log is being filled with messages like this: Oct 13 12:13:08 alkmene kernel: usb 3-1: usbfs: process 16588 (usbhid-ups) did not claim interface 0 before use Oct 13 12:13:40 alkmene last message repeated 43 times

I want to propose to change the format of the entries in the data/driver.list file. Currently the format is (according to the header) # <manufacturer> <model name> <model extra> <driver> Of these fields, the <model extra> field is not very well defined now. For many devices, it contains information about the communication interface used (serial / USB / SNMP) while

Hi everyone, I just want to know about driver support over new APC smart models. My company recently bought a Smart-Ups RT model: SURT3000XLI and a I cannot do to make work it with last version of nut software. Maybe this model it doesn?t supported yet and I want to know if so. The diference with others models like matrix or backup ones is the famous Smart Cable: 940-1525A (utp - db9). I

Hi everyone, I just want to know about driver support over new APC smart models. My company recently bought a Smart-Ups RT model: SURT3000XLI and a I cannot do to make work it with last version of nut software. Maybe this model it doesn?t supported yet and I want to know if so. The diference with others models like matrix or backup ones is the famous Smart Cable: 940-1525A (utp - db9). I

Citeren Arnaud Quette <aquette op alioth.debian.org>: > +.SS "Repetitive timeout and staleness" > + > +Some models tends to be unresponsive with the default polling frequency. > +The result is that your system log will have lots of messages like: > +.nf > + usb 2-1: control timeout on ep0in > + usb 2-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq