Poll UPS failed - Data stale #1022
Comments
|
For the most part the messages indicate that the OS lost the USB device,
not much that NUT can do to fix that part. Might be some power-saving
disabling the chip, or something else frozen on the hub and a USB reset
restarting every connection (either intentionally, or because some vendors
cut corners and implement a port reset same as hub reset).
Guessing by your device name, containing "vm", I might add potentially some
delays or flaws in virtualization/passthrough layer as a possible problem
source.
On a busy machine (hypervisor with many guests, or other
compute/IO/context-switch heavy systems) or on an under-powered machine
(preempted VM just not on CPU) there might also be some exceeded hardcoded
timeouts in any layer of the OS, drivers and software down to libusb used
by NUT driver, perceiving a loss of device because last data exchange was a
bit too long ago.
In that log I see the lost device reported all over April, but the driver
only aborted once? I believe that means retries succeeded to find (maybe
reinitialize) the USB device except once.
For context: which OS and version of NUT (packaged or custom built) is that
happening with? If you do/can run a custom build, are you in position to
check if native libusb-1.0 support from some of the competing branches in
issue #300 would behave better?
|
This is a Debian 10 which runs on a HP ProLiant DL360. I mention this because I can't imagine that such a server has energy saving mechanisms for the USB system. How can I find out if something like this happened at this moment?
It is not a virtual machine but the hypervisor. As platform I use Debian 10 with Proxmox VE.
As already described, the system actually runs a hypervisor. And the system is also relatively busy. But somehow I can't imagine that this is enough to hang up so much.
It seems so yes: the last few months the connection is repeatedly interrupted, only unfortunately today it did not work to restore the connection.
I just tried a few times to compile the branches "libusb-1.0+0.1", "libusb-1.0" and "libusb-compat-1.0" but with no full success: The branches "libusb-1.0+0.1" and "libusb-1.0" I could compile but were unable to use them. I always get the following error message: |
|
That failure to start probably means that it probed available USB devices
and did not find a supported vendor/product ID. Might be that as of those
branches the IDs for your UPS were not known yet, which is unlikely at
least if you were running last release before that, or that the device
remains not seen on the OS side.
Try starting the driver with `-DDDDD` argument for debug with higher
verbosity; it would mention IDs it saw in particular.
…On Thu, Apr 22, 2021, 00:20 HyP3r ***@***.***> wrote:
For the most part the messages indicate that the OS lost the USB device,
not much that NUT can do to fix that part. Might be some power-saving
disabling the chip, or something else frozen on the hub and a USB reset
restarting every connection (either intentionally, or because some vendors
cut corners and implement a port reset same as hub reset).
This is a Debian 10 which runs on a HP ProLiant DL360. I mention this
because I can't imagine that such a server has energy saving mechanisms for
the USB system. How can I find out if something like this happened at this
moment?
Guessing by your device name, containing "vm", I might add potentially some
delays or flaws in virtualization/passthrough layer as a possible problem
source.
It is not a virtual machine but the hypervisor. As platform I use Debian
10 with Proxmox VE.
On a busy machine (hypervisor with many guests, or other
compute/IO/context-switch heavy systems) or on an under-powered machine
(preempted VM just not on CPU) there might also be some exceeded hardcoded
timeouts in any layer of the OS, drivers and software down to libusb used
by NUT driver, perceiving a loss of device because last data exchange was a
bit too long ago.
As already described, the system actually runs a hypervisor. And the
system is also relatively busy. But somehow I can't imagine that this is
enough to hang up so much.
In that log I see the lost device reported all over April, but the driver
only aborted once? I believe that means retries succeeded to find (maybe
reinitialize) the USB device except once.
It seems so yes: the last few months the connection is repeatedly
interrupted, only unfortunately today it did not work to restore the
connection.
For context: which OS and version of NUT (packaged or custom built) is that
happening with? If you do/can run a custom build, are you in position to
check if native libusb-1.0 support from some of the competing branches in
issue #300 <#300> would
behave better?
I just tried a few times to compile the branches "libusb-1.0+0.1",
"libusb-1.0" and "libusb-compat-1.0" but with no full success: The branches
"libusb-1.0+0.1" and "libusb-1.0" I could compile but were unable to use
them. I always get the following error message:
upsdrvctl[44892]: Failed to read pid from
/var/state/ups/usbhid-ups1-myups.pid
upsdrvctl[44892]: Network UPS Tools - Generic HID driver 0.42
(2.7.4-420-g2999c95f)
upsdrvctl[44892]: USB communication driver (libusb 1.0) 0.02
upsdrvctl[44892]: No matching HID UPS found
upsdrvctl[44892]: Driver failed to start (exit status=1)
upsmon[18049]: Poll UPS ***@***.*** failed - Driver not connected
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1022 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFBGJEM4EYPAMYYYDFTTJ5FT3ANCNFSM43LALQWA>
.
|
|
After I called I will inform you in this issue. |
|
thanks!
…On Fri, Apr 23, 2021, 20:00 HyP3r ***@***.***> wrote:
After I called configure Debian conform the library could be compiled and
used. I will now observe the whole thing for a quarter. If it doesn't hang
anymore, the ticket can be closed.
I will inform you in this issue.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1022 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMPTFHCF5A2V3WEJGDDEHTTKGYTVANCNFSM43LALQWA>
.
|
jimklimov
added
PowerWalker
|
OK, I hit this issue, a reboot "fixed" it but I gathered some info before the reboot , might help somebody, esp if the real fix is to raise a kernel defect. (BTW this happened about 10 days after a real power cut...that would have been annoying if it had failed): The messages: Stop and restart nut-server (debian bullseye) The driver failed to start: So it thinks Product is NULL ... (BTW that last line may be key) Looking at: It appears to be there. (also did this as user NUT also OK) Will reboot .. Following reboot ...all seemed to come up OK (UPS WAS NOT power cycled) I noted the following diffs in the output of lsusb: |
jimklimov
added
impacts-release-2.7.4
Hello I have a Bluewalker UPS Powerwalker VI 2200 LCD UPS. Unfortunately, always after some time comes the following error messages:
In this case the server has been running for 55 days. So after 55 days of operation now these error messages come. What could be the reason for this?
lsusb:cat ups.conf:upsd -v:The text was updated successfully, but these errors were encountered: