[Nut-upsuser] CP1500AVRLCD NOCOMM
lanerussell028 at gmail.com
Mon Oct 24 14:38:57 UTC 2016
How could I check if another instance is causing me issues? This is a
running on a KVM host server, so there's very little activity on the server
On Sat, Oct 22, 2016 at 1:16 PM, Charles Lepple <clepple at gmail.com> wrote:
> No, just a few extra hours in the day :)
> This is a tougher problem.
> In the mean time, can you make sure the "Got disconnected by another
> driver " is not really caused by an extra instance of the NUT driver?
> (Could be kernel or other user space activity)
> - Charles
> On Oct 21, 2016, at 11:37 AM, Lane Russell <lanerussell028 at gmail.com>
> Do you need any more info from me on this?
> On Fri, Oct 14, 2016 at 7:56 AM, Lane Russell <lanerussell028 at gmail.com>
>> Increasing 'pollinterval' to 5s did not seem to work. I've attached the
>> relevant portions of the upsdrvctl debug. I believe the message we're
>> looking at is:
>> 9528.632309 libusb_get_report: error sending control message: Device or
>> resource busy
>> 9528.632318 Can't retrieve Report 16: Device or resource busy
>> 9528.632326 Got disconnected by another driver: Device or resource busy
>> On Wed, Oct 12, 2016 at 8:35 AM, Charles Lepple <clepple at gmail.com>
>>> On Oct 12, 2016, at 9:07 AM, Lane Russell wrote:
>>> > Apologies, I did mean upsmon.conf. ups.conf "pollinterval" is not
>>> called out, so I assume it's using the default of 2s. "pollfreq" and
>>> "pollfreqalert" are both set to 10s in upsmon.conf at the moment.
>>> "deadtime" is set to 30s.
>>> No problem, the names are a bit confusing.
>>> > I've attached the output of "sudo /lib/nut/usbhid-ups -a ups -DDD".
>>> I forgot to mention, the list limits messages to ~40 KB, so for the next
>>> time, please compress the log ("gzip -9" or similar).
>>> However, we would need the log at the point where the UPS disconnects.
>>> (The beginning looks normal.) If the compressed log is still large, let me
>>> know and we can trim out the interesting part.
>>> > Forgive me, but I've never rebuilt a driver, and I'm not sure what the
>>> libusb branch is. Could you elaborate? Or perhaps this issue won't be
>>> related to that and we won't have to go down that path.
>>> There are still a few things to try before then, and they are somewhat
>>> related to what the log looks like at the point when the driver declares
>>> the data stale.
>>> Also, maybe I can get things set up again to build packages for an
>>> Ubuntu PPA.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsuser