Jim Klimov
2022-Feb-11 08:31 UTC
[Nut-upsuser] usbhid-ups becomes unresponsive after extended period
So just to clarify - the faulty system uses the older packaged NUT (in Linux) and the newer build of master (in FreeBSD) works better? Does the newer one also use libusb-1.0 dependency (vs. 0.1 likely for packaged one), is the custom build that new? It may be that some transport deficiencies were fixed in that, or in NUT over the years. For that older setup, probably there are some timeout settings to tell the driver to reconnect somehow, but can't remember ATM. Also different systems varied with success of active polling vs interrupt delivery, so "pollonly" (and freq) options can help. On Wed, Feb 9, 2022, 03:56 Gary via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote:> OS name and version: Ubuntu 20.04.3 LTS > NUT Version: 2.7.4 (installed via apt-get) > USB communication driver: 0.33 > Subdriver: APC HID 0.96 > Device: APC Back-UPS 550 > > The usbhid-ups driver seems to stop responding/serving data to upsd after > running it for a few hours. It works initially when starting the NUT > service but would stop working after a while. It would start working again > for a bit if I restart it (sudo upsdrvctl start) > > In my syslog, I would get these error messages once it stops working. > > Feb 8 15:20:43 internal upsmon[25307]: UPS [ups1 at localhost]: connect > failed: Connection failure: Connection timed out > Feb 8 15:20:43 internal upsmon[25307]: UPS ups1 at localhost is unavailable > > Reading the log, the upshid-ups log stops updating after a while. For > example, in this log, it would keep updating until 8282 seconds but nothing > appears in the log afterwards. The command I use to capture the log is: > /usr/lib/nut/usbhid-ups -DDDDD -a ups1 > /var/log/usbhid_log 2>&1 & > > Log file: > > https://drive.google.com/file/d/11LwtnUoF7TweNDxMrIG8ZAxNTlzKwpy7/view?usp=sharing > > The troubleshooting steps I have done include: > - Works without issue: Connecting to a different VM (but on same hardware, > cable port, usb passthrough) running FreeBSD 12.3 and NUT 2.7.4.1 > --- So it doesn't seem to be an issue with hardware, cable, or VM > passthrough issue > > The setup: > - APC Back-UPS connected via USB to USB port on machine, passthrough via > ESXi to guest VM > > Greatly appreciate any insights. > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220211/ef559037/attachment.htm>
Gary
2022-Feb-15 04:39 UTC
[Nut-upsuser] usbhid-ups becomes unresponsive after extended period
Correct - the faulty system uses the older packaged NUT. The working setup in FreeBSD (actually XigmaNAS v12.3.0.4.9848) uses NUT v2021.12.09, which I am guessing is whatever they pulled from Github on that date. Unfortunately, I can only verify that the faulty one (Linux) uses libusb-0.1 and cannot find anything on the libusb for the working FreeBSD. Looking at the changelog for NUT, it seems though that libusb-1.0 were not merged into main NUT codebase until 2022.01.12. So I would guess it is still on libusb-0.1. I took a look at the parameters for usbhid-ups. It seems the most relevant ones would be pollreq, pollonly, interruptonly, interruptsize. Is the strategy here just trial and error since the error log is not showing anything? However, the config used between the two systems are identical so would it still be relevant? ________________________________ From: Jim Klimov <jimklimov+nut at gmail.com> Sent: February 11, 2022 12:31 AM To: Gary <digimon0327 at msn.com> Cc: Arnaud Quette via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> Subject: Re: [Nut-upsuser] usbhid-ups becomes unresponsive after extended period So just to clarify - the faulty system uses the older packaged NUT (in Linux) and the newer build of master (in FreeBSD) works better? Does the newer one also use libusb-1.0 dependency (vs. 0.1 likely for packaged one), is the custom build that new? It may be that some transport deficiencies were fixed in that, or in NUT over the years. For that older setup, probably there are some timeout settings to tell the driver to reconnect somehow, but can't remember ATM. Also different systems varied with success of active polling vs interrupt delivery, so "pollonly" (and freq) options can help. On Wed, Feb 9, 2022, 03:56 Gary via Nut-upsuser <nut-upsuser at alioth-lists.debian.net<mailto:nut-upsuser at alioth-lists.debian.net>> wrote: OS name and version: Ubuntu 20.04.3 LTS NUT Version: 2.7.4 (installed via apt-get) USB communication driver: 0.33 Subdriver: APC HID 0.96 Device: APC Back-UPS 550 The usbhid-ups driver seems to stop responding/serving data to upsd after running it for a few hours. It works initially when starting the NUT service but would stop working after a while. It would start working again for a bit if I restart it (sudo upsdrvctl start) In my syslog, I would get these error messages once it stops working. Feb 8 15:20:43 internal upsmon[25307]: UPS [ups1 at localhost]: connect failed: Connection failure: Connection timed out Feb 8 15:20:43 internal upsmon[25307]: UPS ups1 at localhost is unavailable Reading the log, the upshid-ups log stops updating after a while. For example, in this log, it would keep updating until 8282 seconds but nothing appears in the log afterwards. The command I use to capture the log is: /usr/lib/nut/usbhid-ups -DDDDD -a ups1 > /var/log/usbhid_log 2>&1 & Log file: https://drive.google.com/file/d/11LwtnUoF7TweNDxMrIG8ZAxNTlzKwpy7/view?usp=sharing The troubleshooting steps I have done include: - Works without issue: Connecting to a different VM (but on same hardware, cable port, usb passthrough) running FreeBSD 12.3 and NUT 2.7.4.1 --- So it doesn't seem to be an issue with hardware, cable, or VM passthrough issue The setup: - APC Back-UPS connected via USB to USB port on machine, passthrough via ESXi to guest VM Greatly appreciate any insights. _______________________________________________ Nut-upsuser mailing list Nut-upsuser at alioth-lists.debian.net<mailto:Nut-upsuser at alioth-lists.debian.net> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220215/7033a420/attachment-0001.htm>
Jim Klimov
2022-Feb-15 08:04 UTC
[Nut-upsuser] usbhid-ups becomes unresponsive after extended period
I think yes, so far it is mostly trial and error; we have yet to see a "scientific" body of work explaining what fares better when (OSes; platforms - cpu, virt, powersaving; libusb versions; devices from PC side, usb hubs along the way, usb-serial converters if any, ...), or at least statistics, to help that be more predictable... Seeing comments in libusb detection (m4) and usage (c) code, and googling some discussions, it does seem that freebsd implementation is quite different; so your same configs may well be tapping into unrelated codepaths at that level. On Tue, Feb 15, 2022, 05:39 Gary <digimon0327 at msn.com> wrote:> Correct - the faulty system uses the older packaged NUT. The working setup > in FreeBSD (actually XigmaNAS v12.3.0.4.9848) uses NUT v2021.12.09, which I > am guessing is whatever they pulled from Github on that date. > > Unfortunately, I can only verify that the faulty one (Linux) uses > libusb-0.1 and cannot find anything on the libusb for the working FreeBSD. > Looking at the changelog for NUT, it seems though that libusb-1.0 were not > merged into main NUT codebase until 2022.01.12. So I would guess it is > still on libusb-0.1. > > I took a look at the parameters for usbhid-ups. It seems the most relevant > ones would be pollreq, pollonly, interruptonly, interruptsize. Is the > strategy here just trial and error since the error log is not showing > anything? However, the config used between the two systems are identical so > would it still be relevant? > ------------------------------ > *From:* Jim Klimov <jimklimov+nut at gmail.com> > *Sent:* February 11, 2022 12:31 AM > *To:* Gary <digimon0327 at msn.com> > *Cc:* Arnaud Quette via Nut-upsuser <nut-upsuser at alioth-lists.debian.net> > *Subject:* Re: [Nut-upsuser] usbhid-ups becomes unresponsive after > extended period > > So just to clarify - the faulty system uses the older packaged NUT (in > Linux) and the newer build of master (in FreeBSD) works better? > > Does the newer one also use libusb-1.0 dependency (vs. 0.1 likely for > packaged one), is the custom build that new? It may be that some transport > deficiencies were fixed in that, or in NUT over the years. > > For that older setup, probably there are some timeout settings to tell the > driver to reconnect somehow, but can't remember ATM. Also different systems > varied with success of active polling vs interrupt delivery, so "pollonly" > (and freq) options can help. > > > On Wed, Feb 9, 2022, 03:56 Gary via Nut-upsuser < > nut-upsuser at alioth-lists.debian.net> wrote: > > OS name and version: Ubuntu 20.04.3 LTS > NUT Version: 2.7.4 (installed via apt-get) > USB communication driver: 0.33 > Subdriver: APC HID 0.96 > Device: APC Back-UPS 550 > > The usbhid-ups driver seems to stop responding/serving data to upsd after > running it for a few hours. It works initially when starting the NUT > service but would stop working after a while. It would start working again > for a bit if I restart it (sudo upsdrvctl start) > > In my syslog, I would get these error messages once it stops working. > > Feb 8 15:20:43 internal upsmon[25307]: UPS [ups1 at localhost]: connect > failed: Connection failure: Connection timed out > Feb 8 15:20:43 internal upsmon[25307]: UPS ups1 at localhost is unavailable > > Reading the log, the upshid-ups log stops updating after a while. For > example, in this log, it would keep updating until 8282 seconds but nothing > appears in the log afterwards. The command I use to capture the log is: > /usr/lib/nut/usbhid-ups -DDDDD -a ups1 > /var/log/usbhid_log 2>&1 & > > Log file: > > https://drive.google.com/file/d/11LwtnUoF7TweNDxMrIG8ZAxNTlzKwpy7/view?usp=sharing > > The troubleshooting steps I have done include: > - Works without issue: Connecting to a different VM (but on same hardware, > cable port, usb passthrough) running FreeBSD 12.3 and NUT 2.7.4.1 > --- So it doesn't seem to be an issue with hardware, cable, or VM > passthrough issue > > The setup: > - APC Back-UPS connected via USB to USB port on machine, passthrough via > ESXi to guest VM > > Greatly appreciate any insights. > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20220215/2c3779e7/attachment.htm>