similar to: Suspend-to-disk & NUT (solved?)

I finally nailed down the problem with upsd declaring data stale when resuming from suspend. The problem is two fold (not surprisingly): 1) The dstate_dataok() and dstate_datastale() routines in 'drivers/dstate.c' will only 'broadcast' *changes* in the driver state. Since the driver has no notion of time, it won't notice at all that it was suspended. Therefor, after resuming

> 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

The problem of NUT not operating after returning from a suspend state is located in upsd. I figured that I could try to restart each part of the chain driver->upsd->upsmon separately. Restarting the driver and/or upsmon didn't solve the problem, bur restarting upsd did. So I have come to the conclusion that upsd misses a state change and somehow relies on a cached state. I'm not

I have found that it is impossible to communicate with my UPS when resuming from a suspend-to-disk state. The driver is no longer able to poll the UPS status and eventually will output "Data stale" and never resumes. This may have to do with the UPS itself, the driver (SafeNet, which I wrote and maintain) or with NUT. Suspend itself is OK provided I stop NUT before entering sleep state

I think having this logic buried within libhid/libusb (libusb:libusb_open(), line 179 to 206) is ultimately a mistake, albeit one that I am probably responsible for. Would it make sense to confine libhid to low-level operations, and leave the decision of trying to reopen vs. retrying to open to the high-level driver, in this case usbhid-ups? I envision that the code in usbhid-ups:reconnect_ups()

> - 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: aquette > Date: Thu Jun 21 07:43:46 2007 > New Revision: 971 > > Log: > fix communication lost status handling > > Modified: > trunk/ChangeLog > trunk/drivers/usbhid-ups.c > > Modified: trunk/ChangeLog > ============================================================================== > --- trunk/ChangeLog (original) > +++ trunk/ChangeLog

Are there any plans for using serial PnP in NUT? I tried to implement this on the 'safenet' driver, but the support for this doesn't seem to be widespread among the UPSes compatible with this driver. So far, I have only managed to get one (a Sweex 1000) to output it, but unfortunately, it is probably too generic to be really useful for autodetection: PnP revision : 1.00 PnP EISA ID

The tripplite driver was developed on a machine with a reliable serial connection, and inherited the assumption that the serial line connection would not drop, reorder, or fail character read and writes. This patch adds significantly improved failure mode handling and also does basic checks of data validity. There's also a few minor cleanups/beautification. I've tested this code on my

Citeren Arnaud Quette <aquette.dev op gmail.com>: > Date: Thu, 09 Dec 2010 14:01:14 +0000 > Subject: svn commit r2726 - in branches/windows_port: common drivers include > Author: fbohe-guest > Date: Thu Dec 9 14:01:07 2010 > New Revision: 2726 > URL: http://trac.networkupstools.org/projects/nut/changeset/2726 > > Log: > More work on serial drivers. > Still

While working on the mge-hid subdriver, I wanted to add the 'beeper.mute' command. Unfortunately, the description I intended to use was used already by the 'beeper.off' instcmd: CMDDESC beeper.off "Temporarily mute the UPS beeper" Now of course we could add another instcmd 'beeper.reallyoff', but instead I would prefer to bite the buller and do the following:

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

sent two 0 byte packets to the driver, then it sent 'URB_FUNCTION_SYNC_REST_PIPE_AND_CLEAR_STALL' down the pipe which seems to come back up as well, and then the UPS turned off. I'll play around later with what happens in that regard, although it may be a bit tricky to figure out when the battery is low without having it plugged in ;-) Also, about nut-usbups.rules.in... The

Dear Andreas, some googling revealed, you created a driver for the xanto series of online-usv.de. In what state it is currently? I've to manage a S2000 and would like to use nut for it, is it usable by now? Do you need another tester? TIA, Pete

Hi, I'm new of this list. I installed nut with apt on my ubuntu64, my ups is an elsist and with it I found the Driver's CDROM only for windows. It's branded Fenton but on it there is also printed Safenet. I had no particular problems installing nut with safenet driver. But when I'm trying to connect it with the command: upsc elsist@localhost i get this output driver.name: safenet

We won't need it now, because we will adjust the clocks depending on engine loads later on anyway or a static lockup table. It also simplifies the clocking logic. This code was nowhere used anyway and just a mock up. Signed-off-by: Karol Herbst <karolherbst at gmail.com> Reviewed-by: Martin Peres <martin.peres at free.fr> --- drm/nouveau/include/nvkm/subdev/clk.h | 2 --

We won't need it now, because we will adjust the clocks depending on engine loads later on anyway or a static lookup table. It also simplifies the clocking logic. This code was nowhere used anyway and just a mock up. v2: fixed typo in commit message Signed-off-by: Karol Herbst <karolherbst at gmail.com> Reviewed-by: Martin Peres <martin.peres at free.fr> ---

we won't need them, because we will adjust the clocks depending on engine loads later on anyway. It also simplifies the clocking logic. Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/include/nvkm/subdev/clk.h | 4 ---- drm/nouveau/nvkm/subdev/clk/base.c | 28 ++-------------------------- 2 files changed, 2 insertions(+), 30 deletions(-) diff --git

On 18/04/16 22:13, Karol Herbst wrote: > we won't need them, because we will adjust the clocks depending on engine loads > later on anyway. It also simplifies the clocking logic. You can also say that the code was just mocked up anyway. > > Signed-off-by: Karol Herbst <nouveau at karolherbst.de> > --- > drm/nouveau/include/nvkm/subdev/clk.h | 4 ---- >