Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP
2012/6/10 Tim Gould > I upgraded to trunk (3652) - it worked, but again with the seemingly > spurious RB during DISCHRG. > more than a upsd trace, we need usbhid-ups (-D) to be able to see what's going on... Ie, is the device actually reporting RB (UPS.PowerSummary.PresentStatus.NeedReplacement == 1...) or not. > -DDD output attached. RB turns up just before battery.charge.low is > reached (around 1551 sec), at the same time LB turns up too. > > Once a slave client (on the same UPS) shuts down battery.charge goes back > up above battery.charge.low, so LB goes away, but RB stays. > > I didn't have upsmon running on this host so it ran until the battery was > depleted rather than shutting down. > the above use case should not be a problem, since an initiated shutdown (master + slave) will go to the completion. a variation, where the above result is desired, is load shedding, where you want to shutdown non critical loads, to get more runtime for the critical ones... > Hope this helps, thanks, Tim. > it indeed helps, thanks Tim. cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.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
Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP
Hi Tim, 2012/5/11 Tim Gould : > FWIW I've had this running just fine since my earlier posts. Several power > outages have been dealt with perfectly. > > I haven't had the time to set up and test debug logs around RB but if this is > the sticking point I'll try harder to find that time :) > > I'm happy to pull a fresh version and test. thanks for your feedback. As told in my separate answer, I've just committed Charles' patch to the trunk (r3607). So if you can do some testing, especially on LB/RB, I would be grateful. cheers, Arnaud -- Linux / Unix Expert R&D - 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/ > On 10/05/2012, at 21:58 , Charles Lepple wrote: > >> On May 10, 2012, at 4:38 AM, Arnaud Quette wrote: >> >>> 2012/5/10 Charles Lepple : On May 9, 2012, at 11:27 AM, Arnaud Quette wrote: > this thread has just popped again, but on the Debian side this time: > http://bugs.debian.org/671444 > > what's exactly the situation of fixes WRT issues? > the last mail I have on this thread is attached below... Attached is a patch corresponding to the following branch: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor At this point, it is probably safe to merge. >>> >>> it applies fine on the trunk. >>> should I go ahead and merge it? >> >> Sure, but is it possible to build a .deb for Alastair to test, just to make >> sure we're fixing the same problem? (I'm not sure if Debian has something >> like Ubuntu's PPA system.) >> >> Aside: it is annoying that with a 16-bit field for the USB PID, companies >> insist on reusing the VID:PID combinations for drastically different >> firmware. >> >>> also, does it fix all the known issues related to this scaling factor? >> >> The two potential remaining problems are with ups.load and the RB flag, but >> they are not as critical as the OB/LB flags. >> It does not, however, change the subdriver to liebert-hid. >>> >>> I'm not sure to get all the whizzbang that may hide behind this comment ;-) >>> AFAIK, liebert-hid seems to be for Liebert OEM manufactured by >>> Phoenixtec with a limited set of data. >>> while belkin-hid has a more advanced approach. >>> so it's fine as you did. the problem of subdriver naming is something >>> else, that will never be able to completely address due to mergers, >>> OEM, ... >> >> In this message, Alastair cited Pier's patch which changes the subdriver for >> 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the >> HID usages, we probably could have put the scale fixes in the liebert-hid >> subdriver instead, but I agree that belkin-hid is probably the right mapping >> under the hood. >> >> -- >> Charles Lepple >> clepple@gmail -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671444: [Nut-upsuser] Bug#671444: LiebertPSP
FWIW I've had this running just fine since my earlier posts. Several power outages have been dealt with perfectly. I haven't had the time to set up and test debug logs around RB but if this is the sticking point I'll try harder to find that time :) I'm happy to pull a fresh version and test. On 10/05/2012, at 21:58 , Charles Lepple wrote: > On May 10, 2012, at 4:38 AM, Arnaud Quette wrote: > >> 2012/5/10 Charles Lepple : >>> On May 9, 2012, at 11:27 AM, Arnaud Quette wrote: >>> this thread has just popped again, but on the Debian side this time: http://bugs.debian.org/671444 what's exactly the situation of fixes WRT issues? the last mail I have on this thread is attached below... >>> >>> Attached is a patch corresponding to the following branch: >>> >>> https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor >>> >>> At this point, it is probably safe to merge. >> >> it applies fine on the trunk. >> should I go ahead and merge it? > > Sure, but is it possible to build a .deb for Alastair to test, just to make > sure we're fixing the same problem? (I'm not sure if Debian has something > like Ubuntu's PPA system.) > > Aside: it is annoying that with a 16-bit field for the USB PID, companies > insist on reusing the VID:PID combinations for drastically different firmware. > >> also, does it fix all the known issues related to this scaling factor? > > The two potential remaining problems are with ups.load and the RB flag, but > they are not as critical as the OB/LB flags. > >>> It does not, however, change the subdriver to liebert-hid. >> >> I'm not sure to get all the whizzbang that may hide behind this comment ;-) >> AFAIK, liebert-hid seems to be for Liebert OEM manufactured by >> Phoenixtec with a limited set of data. >> while belkin-hid has a more advanced approach. >> so it's fine as you did. the problem of subdriver naming is something >> else, that will never be able to completely address due to mergers, >> OEM, ... > > In this message, Alastair cited Pier's patch which changes the subdriver for > 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the > HID usages, we probably could have put the scale fixes in the liebert-hid > subdriver instead, but I agree that belkin-hid is probably the right mapping > under the hood. > > -- > Charles Lepple > clepple@gmail > > > > > ___ > Nut-upsuser mailing list > nut-upsu...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
