It looks like I'm currently on 4.4.0-38 uname -a: Linux kvm 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux On Mon, Oct 10, 2016 at 10:04 PM, Charles Lepple <clepple at gmail.com> wrote:> > On Oct 6, 2016, at 7:26 PM, Lane Russell <lanerussell028 at gmail.com> wrote: > > Ubuntu Server 16.04.1 LTS > NUT 2.7.2-4ubuntu1 > > Apologies if you mentioned this already, but which kernel are you running? > > Looking back over the recent USB problems, we saw a lot of problems with > the 3.16 kernel, for instance. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161010/23488977/attachment.html>
On Oct 10, 2016, at 11:32 PM, Lane Russell wrote:> > It looks like I'm currently on 4.4.0-38 > > uname -a: > Linux kvm 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/LinuxAh, right, the default kernel for Ubuntu 16.04. (I am getting the distributions mixed up.) Can you try the libusb-1.0 branch? It's possible to configure NUT using the same options as for the .deb package, so you would only need to rebuild the one usbhid-ups driver. Also, you mentioned "Reducing POLLFREQ & POLLFREQALERT from 5s to 10s". The default value for "pollfreq" in ups.conf is 30 seconds. If you are referring to the POLLFREQ option in upsmon.conf, it does need to be greater than "pollinterval", but you can raise them both. The symptom of having the driver poll the UPS too frequently (as set in ups.conf) is that the driver might overload the USB microcontroller in the UPS, and could cause the UPS to disconnect (as Stuart mentioned for his Tripp Lite UPS). If upsmon polls faster than the driver, then you will also get "data stale" messages, but that is unfortunately not a unique symptom - hence the need for more detailed logs. It looks like your version of "upsdrvctl" doesn't pass "-D" to the driver. For Ubuntu, you can start the driver directly like so: /lib/nut/usbhid-ups -a ups -DDD
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.
?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> wrote:> 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... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161014/44a231b0/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: upsdrvctl_redacted.tar.gz Type: application/x-gzip Size: 6391 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161014/44a231b0/attachment.bin>
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> wrote: > > 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> wrote: >> ?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> wrote: >>> 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... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161022/ee1e9324/attachment.html>
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 itself. 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> > wrote: > > 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> > wrote: > >> ?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> >> wrote: >> >>> 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... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161024/9aab3840/attachment.html>