On Tue, Jan 27, 2015 at 5:53 AM, Charles Lepple <[email protected]> wrote:
> On Jan 24, 2015, at 12:45 AM, Ryan Sizemore <[email protected]> > wrote: > > Hello, > > I am trying to get nut running on a Windows 2012 R2 server (x64). I am > using the MSI release of 2.6.5-3. > > > I am not sure why they are not listed on the main download page, but there > are actually three Windows MSI releases after that: > > http://www.networkupstools.org/package/windows/ > I see. I will try an updated build. > I mention this because there is a memory allocation fix that was released > after your version: > > > https://github.com/networkupstools/nut/commit/a07ff33854bd128115f1d63929f390c982ff410b > > although I suspect it might not be related. > The filter_path function looks to be only used for argument parsing, so yes, it probably isn't related to the issue I am seeing. > > That being said, the Windows port has not been maintained for a year or > two. (This was being developed by Eaton employees, but Eaton is no longer > supporting the NUT project.) > > The attached UPS is an APC xs1500 (model bx1500g). The connection is an > RJ45 to USB cable. > > Here is my ups.conf: > [xs1500] > driver = usbhid-ups > port = auto > desc = "APC Back-UPS xs1500" > > The problem I am encountering is upsd crashing with an 'Out of memory' > error. I can start usbhid-ups.exe and it will correctly dump variables from > the UPS, so communication with the UPS itself seems to work. However, when > I try to run 'upsc xs1500', I get the following output from upsd (running > with debugging output): > > C:\Program Files (x86)\NUT\sbin>upsd -DDDDD > Network UPS Tools upsd 2.6.5-3723:3731M > 0.000000 listen_add: added ::1:3493 > 0.000000 listen_add: added 127.0.0.1:3493 > 0.015628 setuptcp: try to bind to 127.0.0.1 port 3493 > 0.031310 listening on 127.0.0.1 port 3493 > 0.031310 setuptcp: try to bind to ::1 port 3493 > 0.031310 listening on ::1 port 3493 > 0.031310 Connected to UPS [xs1500]: usbhid-ups-xs1500 > 0.046874 mainloop: wait for 4 filedescriptors > <snip> > 33.390678 mainloop: no data available > 33.390678 Pinging UPS [xs1500] > 33.390678 mainloop: wait for 4 filedescriptors > 33.406254 Got PONG from UPS [xs1500] > 33.406254 mainloop: wait for 4 filedescriptors > 34.749994 Out of memory > > > Is there any way for you to put a breakpoint in upsd.c:mainloop(), and > step forward to see what is triggering the "Out of memory" error? > I will see if I can get this running under a debugger, though I imagine I will need to get it building on my on machine first. > > upsc only shows a generic error: > > C:\Program Files (x86)\NUT\bin>upsc xs1500 > Error: Write error: Unknown error > > > After upsd dies, nothing is listening on the socket, so there won't be any > descriptive error messages from upsc. However, I was hoping for something > along the lines of "Connection refused" :-/ > > However, usbhid-upd.exe displays the following: > > C:\Program Files (x86)\NUT\bin>usbhid-ups.exe -a xs1500 -DD > Network UPS Tools - Generic HID driver 0.37 (2.6.5-3723:3731M) > USB communication driver 0.31 > 0.000000 debug level is '2' > 0.000000 upsdrv_initups... > 0.000000 Checking device (051D/0002) > (bus-0/\\.\libusb0-0001--0x051d-0x0002) > 0.015628 - VendorID: 051d > 0.015628 - ProductID: 0002 > 0.031251 - Manufacturer: American Power Conversion > 0.031251 - Product: Back-UPS BX1500G FW:866.L5 .D USB FW:L5 > 0.031251 - Serial Number: 3B1045X04728 > 0.046933 - Bus: bus-0 > 0.046933 Trying to match device > 0.062500 Device matches > 0.091516 HID descriptor length 1133 > 0.092016 Report Descriptor size = 1133 > 0.107654 Using subdriver: APC HID 0.95 > <snip> > 32.094517 upsdrv_updateinfo... > 32.094517 Got 3 HID objects... > 32.110104 Quick update... > 32.813233 Read error : 109 > 34.094483 upsdrv_updateinfo... > 34.110249 Got 2 HID objects... > 34.141355 Full update... > > I'm not sure if the 'Read error' is indicative of anything, but it occurs > exactly when upsd crashes with the 'Out of memory' error. > > > Does the driver keep going after that? > > Yes, the driver keeps running. It prints out "Read error : 109", which I am guessing is the value of errno that is set after calling select() on line 560 of upsclient.c. I could be wrong though. > This is a bit of a shot in the dark (especially because your ProductID of > 0002 is one of the less-broken ones) but do you still get the read error if > you add the "pollonly" option to the UPS-specific part of ups.conf (i.e. > after [xs1500])? > Sadly, no, that doesn't seem to improve the outcome. If feels like upsd fails during a malloc or something similar resulting from the read failure in the driver. If I can get the sources building on my on computer, I will try to debug and see where the exact point of failure is at. Thanks for all the help. > > -- > Charles Lepple > clepple@gmail > > > > -- Ryan Sizemore
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
