[please keep the list CC'd. thanks!] On Mar 13, 2015, at 10:53 AM, Philip Taylor <[email protected]> wrote:
> I’ve set up UPSMON to simply execute ‘shutdown -h now’ and my system shuts > down when I type ‘upsmon -c fsd’. The problem is that the OpenUPS doesn’t > shut down as a result; and therefore when the power comes back on, unless the > battery has totally run out, the system stays dead. Once the battery dies > completely, the UPS will reboot itself and turn the server on - but this may > never happen. > > Do I have to modify the Centos ’shutdown’ script to add to it ‘upsdrvctl > shutdown’ at it’s end point? Or should the fact that upsd is run as a service > (nut-server.service on Centos 7) do this without my intervention? Again, I don't know what CentOS does with its shutdown scripts. Other distributions have some sort of hook that calls 'upsdrvctl shutdown' near the end of the shutdown process. > I’ve looked at ‘ignorelb’. As far as I can tell the OpenUPS never sends LB; > which may be a calibration issue; but there is no documentation to tell you > how this should work. Their documentation talks about ‘coulomb counters’ and > ‘fuel gauges’ but says nothing about how it’s implemented! And I’m waiting > for a response from their support desk. > > You say 'NUT takes a conservative approach to USB HID drivers’. I get a few > errors and I don’t know if they matter. Like : What I meant is that usbhid-ups doesn't try to interpret all of the HID items, just the ones that are known to contain good values (for some version of the UPS firmware). > when I plug in the OpenUPS I see this : > > [ 49.049586] usb 4-5: new full-speed USB device number 3 using ohci-pci > [ 49.215825] usb 4-5: New USB device found, idVendor=04d8, idProduct=d004 > [ 49.222717] usb 4-5: New USB device strings: Mfr=1, Product=2, > SerialNumber=4 > [ 49.229879] usb 4-5: Product: OPEN-UPS > [ 49.233658] usb 4-5: Manufacturer: Mini-Box.Com > [ 49.238218] usb 4-5: SerialNumber: PBSO4-LiFePO > [ 49.259143] hid-generic 0003:04D8:D004.0002: invalid report_size 248 > [ 49.265603] hid-generic 0003:04D8:D004.0002: item 0 1 1 7 parsing failed > [ 49.272485] hid-generic: probe of 0003:04D8:D004.0002 failed with error -22 You can ignore the hid-generic errors; NUT detaches that kernel driver and bypasses it with libusb. That said, it means the HID descriptor has some syntax issues. > If I manually run 'upsdrvctl start’ I get this : > > USB communication driver 0.32 > Using subdriver: openUPS HID 0.4 > libusb_get_string: Invalid argument > libusb_get_string: Invalid argument The driver should only call libusb_get_string() for informational purposes, so it should only affect ups.mfr and ups.model in upsc. > > And if I run upsd with high level of debug, after working OK for a while, I > see these ‘broken pipe’ messages : > > 0.419974 Entering libusb_get_report > 0.421967 Report[get]: (4 bytes) => 60 c4 ff 3b > 0.422056 PhyMax = 0, PhyMin = 0, LogMax = 16777215, LogMin = 0 > 0.422069 Unit = 00001001, UnitExp = 0 > 0.422080 Exponent = 0 > 0.422093 hid_lookup_path: 00840004 -> UPS > 0.422107 hid_lookup_path: 00840024 -> PowerSummary > 0.422121 hid_lookup_path: 00850068 -> RunTimeToEmpty > 0.422146 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Feature, ReportID: > 0x60, Offset: 0, Size: 24, Value: 3.9321e+06 That looks like a calibration problem: 3.9 million seconds of runtime is a while. > 0.422163 Report[buf]: (4 bytes) => 60 c4 ff 3b > 0.422177 PhyMax = 0, PhyMin = 0, LogMax = 16777215, LogMin = 0 > 0.422188 Unit = 00001001, UnitExp = 0 > 0.422198 Exponent = 0 > 0.422209 hid_lookup_path: 00840004 -> UPS > 0.422221 hid_lookup_path: 00840024 -> PowerSummary > 0.422234 hid_lookup_path: 00850068 -> RunTimeToEmpty > 0.422253 Path: UPS.PowerSummary.RunTimeToEmpty, Type: Input, ReportID: 0x > 60, Offset: 0, Size: 24, Value: 3.9321e+06 > 0.422264 Entering libusb_get_report > 0.423983 Can't retrieve Report b1: Broken pipe > 0.424034 hid_lookup_path: ff000001 -> not found in lookup table > 0.424060 hid_lookup_path: ff000001 -> not found in lookup table > 0.424076 Path: ff000001.ff000001, Type: Output, ReportID: 0xb1, Offset: 0 > , Size: 248 > 0.424089 Entering libusb_get_report > 0.425933 Can't retrieve Report b2: Broken pipe > 0.425953 hid_lookup_path: ff000001 -> not found in lookup table > 0.425966 hid_lookup_path: ff000001 -> not found in lookup table > 0.425980 Path: ff000001.ff000001, Type: Input, ReportID: 0xb2, Offset: 0, > Size: 248 > 0.425992 Entering libusb_get_report > 0.427956 Can't retrieve Report 81: Broken pipe > 0.428006 hid_lookup_path: ff000001 -> not found in lookup table > 0.428021 hid_lookup_path: ff000001 -> not found in lookup table > 0.428036 Path: ff000001.ff000001, Type: Output, ReportID: 0x81, Offset: 0 > , Size: 248 > 0.428048 Entering libusb_get_report > 0.429891 Can't retrieve Report 82: Broken pipe > 0.429911 hid_lookup_path: ff000001 -> not found in lookup table > 0.429925 hid_lookup_path: ff000001 -> not found in lookup table > 0.429939 Path: ff000001.ff000001, Type: Input, ReportID: 0x82, Offset: 0, > Size: 248 > 0.429950 Entering libusb_get_report Can you send a copy of the debug output (-DDD) from starting the driver for ~30 seconds, gzip'd and attached? -- Charles Lepple clepple@gmail
_______________________________________________ Nut-upsuser mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
