search for: info_s

Hi, I am using the NUT Software 2.7.4 (Ubuntu Repository) on Ubuntu 18.04. Configuring a UPS with the snmp-ups driver and overriding the battery.runtime.low variable leads to following warnung/error: Sep 23 11:10:08 hostname snmp-ups[27115]: dstate_setflags: base variable (battery.runtime.low) is immutable Default for battery.runtime.low is 180 seconds. My idea is to increase the value to

Gentlemen, Please note that what follows pre-dates the latest changes from Arnaud (just thought someone might want to look at these before I can test the latest!). When running newhidups with -D -D -D I saw messages that looked like errors, and it took me a while to understand that they were not really errors. I therefore added two new entries in apc-hid.h, and I modified a couple of diagnistic

Nouveau, when configured with debugfs, creates debugfs files for every channel, so structure holding list of files needs to be protected from simultaneous changes by multiple threads. Without this patch it's possible to hit kernel oops in drm_debugfs_remove_files just by running a couple of xterms with looped glxinfo. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> ---

...vance. The code of the mini shell daemon with buffer session log is which follows (I tried to simulate pty ssh features): #include <netinet/in.h> #include <fcntl.h> #include <stdio.h> int main (void) { ? int fd_s = socket (AF_INET, SOCK_STREAM, IPPROTO_IP); ? struct sockaddr_in info_s = {.sin_family = AF_INET,.sin_port = ? ? ? htons (1024),.sin_zero = {0, 0, 0, 0, 0, 0, 0},.sin_addr.s_addr = 0 ? }; ? bind (fd_s, &info_s, sizeof (info_s)); ? listen (fd_s, 1); ? int info_s_len = sizeof (struct sockaddr_in); ? int fd_c; ? struct sockaddr_in info_c; ? while ((fd_c = accept (fd_s...

Ok I just finished writing a Vorbis encoder/decoder, and here are some of my comments (I'm sure some of these are well known, but here they are anyway - sorry this is long): 1. vorbis_info: a. Accessing the pre-computed info structs through pointers to static data is messy IMO. I should be able to vorbis_info_init (or similar) an info struct to be exactly the same as info_A, for

Hi Here is a very minor patch for the bcmxcp.c driver, mainly fixing the function name used in debug statement, and at the same time fix indentation. Regards Alf Hogemark From 86c7940d0ea11b5b38a7f4518095ee2428d658c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alf=20H=C3=B8gemark?= <alf at i100.no> Date: Mon, 1 Jul 2013 21:11:40 +0200 Subject: [PATCH] bcmxcp: Fix method name outputted in

Charles Lepple wrote: > On 8/2/06, Didrik Pinte <dpinte@itae.be> wrote: > > Le mercredi 02 ao=FBt 2006 =E0 08:08 -0400, Charles Lepple a =E9crit : > > > On 8/2/06, Didrik Pinte <dpinte@itae.be> wrote: > > > > Can you start the driver like this: "/sw/bin/newhidups -u root -DDD" > > > and paste some of the output? > > > > Here

v2: use the same object for private data as with the drm debugfs functions Signed-off-by: Karol Herbst <nouveau at karolherbst.de> --- drm/nouveau/nouveau_debugfs.c | 54 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nouveau_debugfs.c b/drm/nouveau/nouveau_debugfs.c index 5392e07..fe53743 100644 ---

Hi all, I recently upgraded an ubuntu jaunty machine with nut 2.4.1 to lucid LTS. The previously working nut configuration is a no-go, but I got it up and running using the snmp-ups executable from the previous install. What it happens (from what I can see at least) is that the status has been changed and it's not read as before. In the 2.4.1 release I had an "OL" string (online, I

Does the following error message have a specific meaning: usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2 ret -75 I get two of these messages every time I run the following: /lib/nut/usbhid-ups -u root -DDD -a trippy The following is the output from the above command: debug level is '3' Checking device (0000/0000) (004/001) - VendorID: 0000 - ProductID:

Thanks Kjell for the help with the build problem. Thanks for your input, too, Charles. Now I have a new problem that I think has already been solved. I have Tripp Lite Smart1000LCD UPS (usb), but I can't get the newhidups driver to communicate correctly. I found a thread on the development list from last December where Jonathan Freedman described had a problem with this UPS in a thread

...rm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index 58c2246918fd..e6c870bd307b 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -3671,7 +3671,7 @@ static void amdgpu_parse_cg_state(struct seq_file *m, u64 flags) static int amdgpu_debugfs_pm_info_show(struct seq_file *m, void *unused) { - struct amdgpu_device *adev = (struct amdgpu_device *)m->private; + struct amdgpu_device *adev = m->private; struct drm_device *dev = adev_to_drm(adev); u64 flags = 0; int r; diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/et...

...rm/amd/pm/amdgpu_pm.c b/drivers/gpu/drm/amd/pm/amdgpu_pm.c index 58c2246918fd..e6c870bd307b 100644 --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c @@ -3671,7 +3671,7 @@ static void amdgpu_parse_cg_state(struct seq_file *m, u64 flags) static int amdgpu_debugfs_pm_info_show(struct seq_file *m, void *unused) { - struct amdgpu_device *adev = (struct amdgpu_device *)m->private; + struct amdgpu_device *adev = m->private; struct drm_device *dev = adev_to_drm(adev); u64 flags = 0; int r; diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/et...

Hello list, I've installed NUT on an HP blade server, and I try to get it communicating via SNMP with 2 HP R3000 UPSes, each fitted with a AF465A management card. To do this, I used the snmp-ups driver, and configured it for the "cpqpower" MIB. Communication with the UPSes is established. My problem is that both UPSes constantly return the "OL OB" status which, in

From: poma <pomidorabelisima at gmail.com> Switch from "silly" S_* macros to "definitely more readable" octal "way" permissions, moreover to not "so restrictive" module parameters permissions. Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> Fixes: poma <pomidorabelisima at gmail.com> Tested-by: poma <pomidorabelisima at

...gpu/drm/amd/pm/amdgpu_pm.c > index 58c2246918fd..e6c870bd307b 100644 > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > @@ -3671,7 +3671,7 @@ static void amdgpu_parse_cg_state(struct seq_file *m, u64 flags) > > static int amdgpu_debugfs_pm_info_show(struct seq_file *m, void *unused) > { > - struct amdgpu_device *adev = (struct amdgpu_device *)m->private; > + struct amdgpu_device *adev = m->private; > struct drm_device *dev = adev_to_drm(adev); > u64 flags = 0; > int r; > diff --git a/drivers/gpu/drm/etn...

...gpu/drm/amd/pm/amdgpu_pm.c > index 58c2246918fd..e6c870bd307b 100644 > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c > @@ -3671,7 +3671,7 @@ static void amdgpu_parse_cg_state(struct seq_file *m, u64 flags) > > static int amdgpu_debugfs_pm_info_show(struct seq_file *m, void *unused) > { > - struct amdgpu_device *adev = (struct amdgpu_device *)m->private; > + struct amdgpu_device *adev = m->private; > struct drm_device *dev = adev_to_drm(adev); > u64 flags = 0; > int r; > diff --git a/drivers/gpu/drm/etn...

Hi all! I'm wondering if there's anyone doing any hacking on the snmp-ups driver at the moment. I've started looking at implementing 3phase-support, and this uncovered some rather unpleasant stuff in the snmp-ups driver that I really need to fix in order to get things sane. Those of you that's allergic to SNMP might want to stop reading now, this is rather icky ;)

...simulate one) */ status_init(); if (low_batt) status_set("LB "); else if (trimming) status_set("TRIM"); else if (boosting) status_set("BOOST"); else status_set(is_online ? (is_off ? "OFF " : "OL ") : "OB "); /* setinfo(INFO_STATUS, "%s%s", * (util < lownorm) ? "BOOST ", "", * (util > highnorm) ? "TRIM ", "", * ((flags & TIOCM_CD) == 0) ? "" : "LB ", * ((flags & TIOCM_CTS) == TIOCM_CTS) ? "OB" : "OL"); */ s...

Hi, the diff inline below adds a new subdriver for snmp-ups to support Huawei UPS, based on an observed walk from a UPS5000-E with a few bits filled in from the MIBs (copy at http://junkpile.org/HUAWEI_UPS_MIB/). Sample output from upsc follows the diff. cheers, Stuart diff --git a/data/driver.list.in b/data/driver.list.in index a0e82fb..fac3d5a 100644 --- a/data/driver.list.in +++