Re: [Nut-upsuser] Support of amp; amp; quot; shutdown.returnamp; amp; quot; on a APC Back-UPS CS 500
Arjen de Korte nut+users at de-korte.org writes:
Citeren Kevin bakdong at gmail.com:
Have you tried the latest version (nut-2.6.0) that was released only a
couple of days ago? Chances are that it might just work, since we have
seen reports about people running the CS 500 in recent years.
Yes, I have now had a chance to try this version and can confirm that it
does
not work on either the Smart-1000 or the CS 500. It shuts them both
down, never
to start up again without operator intervention.
Please post the first 30 seconds worth of
/path/to/usbhid-ups -DD -u root -a upsname APC_CS500.txt 21
here. Make sure to stop any running driver before doing so and be so
kind to zip the resulting logfile.
(I should make it clear that I only use these in a server
environment, so I am
only interested in the shutdown function for the PC and the sleep/hibernate
commands for the UPS.)
I have also done some experimenting with the working executables that I
have,
running them in debug mode. The output of the hidups indicated
setvalue(0xff860077c,1) so I modified the code from nut-2.0.0 as follows:
void upsdrv_shutdown(void)
{
/* XXX: replace with a proper shutdown function
fatalx(shutdown not supported); */
/* 1) set DelayBeforeStartup */
if (getval (ondelay))
ondelay = atoi (getval (ondelay));
/* setvalue(UPS_WAKEDELAY, ondelay); */ /* commented out
this line for
APC CS 500 */
/* 2) set DelayBeforeShutdown */
if (getval (offdelay))
offdelay = atoi (getval (offdelay));
/* setvalue(UPS_GRACEDELAY, offdelay); */
setvalue(0xff86007c, 1);
}
This version is way too old to be of any use. We already know that
0xff86007c is APCDelayBeforeReboot and we already try that after the
shutdown.return command fails. Only if that one fails too, we use
load.off.delay.
I haven't finished testing the Smart-1000 yet. I have code that works, and
outputs the following:
Initiating UPS shutdown
upsdrv_shutdown...
instcmd(shutdown.return, [NULL])
find_nut_info: unknown info type: shutdown.return
instcmd(load.on.delay, [NULL])
find_nut_info: unknown info type: load.on.delay
instcmd: info element unavailable load.on.delay
instcmd(shutdown.reboot, [NULL])
Report[set]: (4 bytes) = 13 0a 00 00
upsdrv_cleanup...
This is what the nut-2.6.0 usbhid-ups driver will do by default, so
I'm not surprised. Double check which version of the driver you're
running in your tests (preferably by checking with 'upsc'). I will not
answer further messages unless you make clear which version of the
driver you're running and whether or not you modified it.
Best regards, Arjen
Hi Arjen,
I have some more results for you:
After a further day testing, I have found that the two devices behave
differently.
To avoid any confusion, I ran the following:
wget http://www.networkupstools.org/source/2.6/nut-2.6.0.tar.gz
tar xvf nut-2.6.0.tar.gz (note: despite the name, this is not a gzipped
file)
cd nut-2.6.0
./configure --prefix= --sysconfdir=/etc/ups --with-statepath=/var/run/nut --
with-user=nut --with-group=uucp --without-serial
make
cd drivers/
./usbhid-ups -D -k -a apc1500
Last few lines of output:
0.686042 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature,
ReportID: 0x14, Offset: 0, Size: 8, Value: 2
0.686059 send_to_all: ADDCMD beeper.disable
0.686075 hid_lookup_usage: UPS - 00840004
0.686092 hid_lookup_usage: PowerSummary - 00840024
0.686107 hid_lookup_usage: AudibleAlarmControl - 0084005a
0.686121 string_to_path: depth = 3
0.686139 Report[buf]: (2 bytes) = 14 02
0.686154 PhyMax = 0, PhyMin = 0, LogMax = 3, LogMin = 1
0.686168 Unit = , UnitExp = 0
0.686182 Exponent = 0
0.686198 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature,
ReportID: 0x14, Offset: 0, Size: 8, Value: 2
0.686228 send_to_all: ADDCMD beeper.mute
0.686250 send_to_all: ADDCMD load.off
0.686274 send_to_all: ADDCMD load.on
0.686293 send_to_all: ADDCMD shutdown.return
0.686310 send_to_all: ADDCMD shutdown.stayoff
0.686325 Initiating UPS shutdown
0.686340 upsdrv_shutdown...
0.686365 instcmd(shutdown.return, [NULL])
0.686382 find_nut_info: unknown info type: shutdown.return
0.686398 instcmd(load.on.delay, 30)
0.686433 Unit = 1001, UnitExp = 0
0.686450 Exponent = 0
0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.690437 Report[set]: (3 bytes) = 28 1e 00
0.690437 Set report succeeded
0.690437 instcmd: SUCCEED
0.690437 instcmd(load.off.delay, 20)
0.690437 Unit = 1001, UnitExp = 0
0.690437 Exponent = 0
0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1
0.695437
Re: [Nut-upsuser] Support of amp; amp; quot; shutdown.returnamp; amp; quot; on a APC Back-UPS CS 500
Citeren Kevin bakd...@gmail.com: 0.686325 Initiating UPS shutdown 0.686340 upsdrv_shutdown... 0.686365 instcmd(shutdown.return, [NULL]) 0.686382 find_nut_info: unknown info type: shutdown.return This is normal. Some UPS'es (models that have a HID layer around an essential serial interface) support a command that will result in what NUT calls 'shutdown.return', so that's what we try first. A true HID PDC UPS (like the APC models you have) don't, so this command is not found. This is exactly what we expect. 0.686398 instcmd(load.on.delay, 30) 0.686433 Unit = 1001, UnitExp = 0 0.686450 Exponent = 0 0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1 0.690437 Report[set]: (3 bytes) = 28 1e 00 0.690437 Set report succeeded 0.690437 instcmd: SUCCEED In a HID PDC UPS, you need to set both the timer for shutdown and (re)start independently. They start counting down immediately after setting the report, so we set the (re)start timer... 0.690437 instcmd(load.off.delay, 20) 0.690437 Unit = 1001, UnitExp = 0 0.690437 Exponent = 0 0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1 0.695437 Report[set]: (3 bytes) = 12 14 00 0.695437 Set report succeeded 0.695437 instcmd: SUCCEED ...before the stop timer, so that we don't get stuck if the power is lost. In that case, the (re)start timer will have expired and a UPS will not start again. APC CS 500 This shuts down the APC CS 500 after 20 seconds. (and it stays shutdown) This probably means the driver called 'load.off.delay 20', which is the last resort option for the usbhid-ups. It looks like it doesn't have a mapping for 'shutdown.reboot', which the logs you have produced should reveal. APC Smart-UPS 1000 If the power is left on, switches to battery and back online after 2 seconds. Either the HID PDC implementation in this UPS is broken or what you're seeing is 'shutdown.reboot'. The timers are in seconds and with mains present, the UPS should stop 20 seconds after running this command and resume again 10 (30-20) seconds later. If the power is off, goes to sleep after 90 seconds. (and comes back on when the power is connected) This is broken either way. There is nothing we can do about that. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of amp; amp; amp; quot; shutdown.returnamp; amp; amp; quot; on a APC Back-UPS CS 500
Arjen de Korte nut+users at de-korte.org writes: Citeren Kevin bakdong at gmail.com: 0.686325 Initiating UPS shutdown 0.686340 upsdrv_shutdown... 0.686365 instcmd(shutdown.return, [NULL]) 0.686382 find_nut_info: unknown info type: shutdown.return This is normal. Some UPS'es (models that have a HID layer around an essential serial interface) support a command that will result in what NUT calls 'shutdown.return', so that's what we try first. A true HID PDC UPS (like the APC models you have) don't, so this command is not found. This is exactly what we expect. 0.686398 instcmd(load.on.delay, 30) 0.686433 Unit = 1001, UnitExp = 0 0.686450 Exponent = 0 0.686464 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1 0.690437 Report[set]: (3 bytes) = 28 1e 00 0.690437 Set report succeeded 0.690437 instcmd: SUCCEED In a HID PDC UPS, you need to set both the timer for shutdown and (re)start independently. They start counting down immediately after setting the report, so we set the (re)start timer... 0.690437 instcmd(load.off.delay, 20) 0.690437 Unit = 1001, UnitExp = 0 0.690437 Exponent = 0 0.690437 PhyMax = 0, PhyMin = 0, LogMax = 32767, LogMin = -1 0.695437 Report[set]: (3 bytes) = 12 14 00 0.695437 Set report succeeded 0.695437 instcmd: SUCCEED ...before the stop timer, so that we don't get stuck if the power is lost. In that case, the (re)start timer will have expired and a UPS will not start again. APC CS 500 This shuts down the APC CS 500 after 20 seconds. (and it stays shutdown) This probably means the driver called 'load.off.delay 20', which is the last resort option for the usbhid-ups. It looks like it doesn't have a mapping for 'shutdown.reboot', which the logs you have produced should reveal. APC Smart-UPS 1000 If the power is left on, switches to battery and back online after 2 seconds. Either the HID PDC implementation in this UPS is broken or what you're seeing is 'shutdown.reboot'. The timers are in seconds and with mains present, the UPS should stop 20 seconds after running this command and resume again 10 (30-20) seconds later. If the power is off, goes to sleep after 90 seconds. (and comes back on when the power is connected) This is broken either way. There is nothing we can do about that. Best regards, Arjen Thanks for the response. I have to say that this is way beyond me. We know that the UPS models in question support the function that we want (sleep/hibernate), and we know the command that is needed to initiate that state. It's been working in previous releases on at least the Smart-UPS 1000, and it was working with a small amendment to the code on the old hidups module. It's a shame that I can't seem to get the up to date releases working properly on both of these UPS models, specially after seeing that it can be done, apparently fairly simply, by sending the 0xff86007c code in both cases. Anyway, at lease I have now shared the very limited knowledge that I have gained from the exercise with the NUT user community, so maybe, hopefully, someone will be able to benefit from it in the future. Regards, Kevin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Support of amp; amp; amp; quot; shutdown.returnamp; amp; amp; quot; on a APC Back-UPS CS 500
Citeren Kevin bakd...@gmail.com: It's a shame that I can't seem to get the up to date releases working properly on both of these UPS models, specially after seeing that it can be done, apparently fairly simply, by sending the 0xff86007c code in both cases. As far as I can tell from your previous message, it works (with nut-2.6.0) for the Smart-UPS 1000, right? Anyway, at lease I have now shared the very limited knowledge that I have gained from the exercise with the NUT user community, so maybe, hopefully, someone will be able to benefit from it in the future. They won't, because you have not posted the logs I asked you about. Only those will be able to provide us with the needed information about how to talk to your UPSes. We don't expect you to modify the code, but at least provide us with enough info so that one of the developers can do it. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd crashes with a broken pipe error
2011/1/16 Zach La Celle lace...@roboticresearch.com
On 01/11/2011 03:38 AM, Arnaud Quette wrote:
Hi Zach,
2011/1/10 Zach La Celle lace...@roboticresearch.com
On 01/06/2011 08:06 AM, Arnaud Quette wrote:
2011/1/5 Zach La Celle lace...@roboticresearch.com
On 01/04/2011 08:20 AM, Arnaud Quette wrote:
2011/1/4 Charles Lepple clep...@gmail.com
On Mon, Jan 3, 2011 at 8:29 AM, Zach La Celle
lace...@roboticresearch.com wrote:
On 12/29/2010 10:00 AM, Zach La Celle wrote:
On 12/29/2010 08:34 AM, Charles Lepple wrote:
On Dec 27, 2010, at 9:36 AM, Zach La Celle wrote:
I ran this in debug mode and captures the backtrace.
root@*:/etc/nut# upsd -D
Network UPS Tools upsd 2.4.3
0.00 listening on 0.0.0.0 port 3493
0.000354 Connected to UPS [rack1ups]: apcsmart-rack1ups
2.550554 User upsmon@127.0.0.1 logged into UPS [rack1ups]
*** glibc detected *** upsd: free(): invalid next size (fast):
0x012c9870 ***
Can you give us some background information about this system? What
OS
and version, who built the package, etc.
Just to be sure, are you running the Ubuntu-provided package, or
something from another package repository? Which version of Ubuntu?
Running valgrind might produce similarly opaque results without debug
symbols (which you can enable if you build from source).
debug syms are available as separate debs.
As an example, for Ubuntu, look here:
https://wiki.kubuntu.org/DebuggingProgramCrash
then look for installing {nut,libupsclient}-dbgsym and others if needed
otherwise...
That is a bit
more involved, though (especially if you want to keep the installed
files in the same place) so I'd try that after Arjen's suggestion with
-DDD.
seconded for a first run.
cheers,
Arnaud
--
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
The only extra package I could find is the dev package. I'm not
sure if that contains debugging symbols.
I'm running with the -DDD option now. It hasn't crashed over the
weekend, so we'll see how long it takes to crash now. I'm getting source to
try and rebuild it so that I can walk through in GDB if necessary.
have you looked at the pointer I've sent, *and* applied the various
mentioned actions (adding key and repository, refresh apt cache, ...)?
otherwise, you won't see these packages!
I still fail to see what is your exact system (Ubuntu? which version?)
apart from the arch which is x86_64...
cheers,
Arnaud
--
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
I'm having trouble finding the upsd source code, or maybe I just don't
understand how to run it properly. The source I have for ubuntu/lucid seems
to either be for a different UPSD project, or to run very differently than
the version off of the Ubuntu repositories. Can you point me to the correct
source for upsd?
to get the one for your binary, check that you have a deb-src line for
main in your /etc/apt/sources.list
then apt-get source nut
or get the source here: http://packages.ubuntu.com/maverick/nut
note that upsd package is a completely different project.
cheers,
Arnaud
--
Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
I now have the upsd source package installed and built for debug, but when
I run upsd I get errors connecting to my UPS. I copied all of the
configuration files from my normal config directory (/etc/nut) into the new
directory (/usr/local/ups/etc/), but I get an Error; cannot find rack1ups;
no such file or directory or something along those lines. I've tried to
fix this myself but it just doesn't seem to be working. Any idea?
in order to have a source compilation working in a Debian / derivative env.,
you need to configure using the following flags:
./configure --prefix=/usr \
--exec-prefix=/ \
--sysconfdir=/etc/nut \
--mandir=/usr/share/man \
--libdir=/lib \
--includedir=/usr/include \
--without-ssl \
--with-hal \
--with-cgi \
--with-dev \
--enable-static \
--with-statepath=/var/run/nut \
--with-altpidpath=/var/run/nut \
--with-drvpath=/lib/nut \
--with-cgipath=/usr/lib/cgi-bin/nut \
--with-htmlpath=/usr/share/nut/www \
--with-pidpath=/var/run/nut \
--datadir=/usr/share/nut \
