Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
On 06/18/2011 06:02 AM, Charles Lepple wrote:
By the way, this is fairly broken behavior on the part of the UPS firmware.
There are standards-compliant ways for a USB device to suspend after
inactivity
while still remaining connected to the bus.
I don't know if this UPS has upgradeable firmware, but if it were mine, I'd
let
the manufacturer know.
I will pass this info on to CyberPower. I'm not sure if the firmware is
upgradable, I would guess not. Their HID models seem to all be cheaper consumer
oriented products.
To tell the truth, I really questioned if it was worth pursuing this issue. It
seemed pretty clear from the beginning that the whole problem was in some way
caused by the device (since other usb devices seem to work).
Since you correctly diagnosed the situation as being the device itself that
terminates the connection, it seemed to me that the only real benefit to be
gained was to improve the ability, of linux-usb and nut, to deal with such
misbehaving hardware.
So this is why I've continued to pursue this instead of just throwing these
units in the trash and buying something that works (really, it's not just to
badger you guys 8-)
What if you add the loop in the script that starts the driver (through
upsdrvctl)? That might be easier to prototype.
I tried to do this, but failed again. I tried to loop on the execv for the
forked child process, in forkexec() called from start_driver(). There's probably
a better place to locate the loop, but I haven't found it yet. (patch attached
for reference)
Thanks for your support!
johnea
--- src/nut-2.6.1/drivers/upsdrvctl.c 2011-05-31 03:36:49.0 -0700
+++ upsdrvctl.c 2011-06-19 11:58:24.0 -0700
@@ -180,6 +180,7 @@
static void forkexec(char *const argv[], const ups_t *ups)
{
int ret;
+ int retry;
pid_t pid;
pid = fork();
@@ -237,7 +238,13 @@
/* child */
- ret = execv(argv[0], argv);
+ /* retry driver launch due to disconnecting CyberPower HID UPS
2011-06-19 -jea */
+ for (retry=0; retry 3; retry++)
+ {
+ ret = execv(argv[0], argv);
+ upslogx(LOG_WARNING, Retrying driver start: %d, retry+1);
+ sleep(3);
+ }
/* shouldn't get here */
fatal_with_errno(EXIT_FAILURE, execv);
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
On 06/17/2011 12:31 AM, Arnaud Quette wrote:
2011/6/16 Charles Lepple clep...@gmail.com
On Jun 15, 2011, at 5:40 PM, n...@johnea.net wrote:
(...)
Is it consistently disconnecting every 20 seconds? That almost sounds like
some proprietary extension to the HID protocol - the UPS expects the
computer to send something that only the CyberPower software knows to send.
in this case, doing an usbsnoop run is the way to go:
http://lists.alioth.debian.org/pipermail/nut-upsdev/2010-February/004528.html
It seems the usbhid-ups driver already knows how to make the UPS happy. Once the
driver has successfully connected to the UPS, the disconnect/reconnect cycle
stops and the UPS stays connected and communicating from then on.
It only misses connecting if the device is given enough time to disconnect
(presumably because it timed out after 20sec).
Unless the administrator can guarantee to _always_ connect to the device within
20sec of boot, the usbhid-ups needs to delay a second or two and then retry, 2
or 3 times, before giving up on finding the CyberPower subdriver based UPS.
cheers,
Arnaud
Thank You Arnaud!
p.s. I tried to make a patch for this, but it failed, attached for reference
--- src/nut-2.6.1/drivers/usbhid-ups.c 2011-05-31 03:36:49.0 -0700
+++ usbhid-ups.c2011-06-17 14:11:30.0 -0700
@@ -860,6 +860,7 @@
void upsdrv_initups(void)
{
int ret;
+ int retry;
char *val;
#ifdef SHUT_MODE
/*!
@@ -906,7 +907,15 @@
/* Search for the first supported UPS matching the
regular expression (USB) or device_path (SHUT) */
- ret = comm_driver-open(udev, curDevice, subdriver_matcher,
callback);
+/* retry HID UPS connection 2011-06-17 -jea */
+for (retry=0, ret=0; retry3 ret1; retry++) {
+ ret = comm_driver-open(udev, curDevice, subdriver_matcher,
callback);
+if (ret 1) {
+retry++;
+upsdebugx(1, Retry Detection of HID UPS: %d, retry);
+sleep(1);
+}
+}
if (ret 1)
fatalx(EXIT_FAILURE, No matching HID UPS found);
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
On Jun 15, 2011, at 5:40 PM, n...@johnea.net wrote: On 06/15/2011 02:24 PM, n...@johnea.net wrote: - Does this seems to indicate the conflict of drivers you mentioned? usbtree data that may indicate driver conflict is the issue: I think Arnaud was referring to the case where two instances of NUT have been installed, and both user-space drivers are trying to re-open the device. The usbhid driver mentioned below is a kernel driver, and unless there is a regression in the kernel driver detach code, that shouldn't be an issue. The output of usbtree when the device is disconnecting: /: Bus 04.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M |_ Port 1: Dev 26, If 0, Prod=CP425HG, Class=HID, Drv=usbhid, 1.5M The output of usbtree once usbhid-ups has succesfully connected: /: Bus 04.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M |_ Port 1: Dev 27, If 0, Prod=CP425HG, Class=HID, Drv=usbfs, 1.5M Is there a udev rule that can block the usbhid driver from connecting to the device? There is a blacklist in the kernel, but I don't think this is the issue here. The UPS shouldn't be completely disconnecting, even if two drivers are fighting over it. (If that's the case, you just get a volley of EBUSY errors between the two drivers.) Double-check the cabling, because disconnect messages such as the following are reported to the kernel by the USB host controller chip: Jun 8 18:07:28 sensor003 kernel: [ 411.500020] usb 3-2: USB disconnect, address 19 Is it consistently disconnecting every 20 seconds? That almost sounds like some proprietary extension to the HID protocol - the UPS expects the computer to send something that only the CyberPower software knows to send. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
On 06/16/2011 04:15 AM, Charles Lepple wrote: Double-check the cabling, because disconnect messages such as the following are reported to the kernel by the USB host controller chip: Jun 8 18:07:28 sensor003 kernel: [ 411.500020] usb 3-2: USB disconnect, address 19 Is it consistently disconnecting every 20 seconds? That almost sounds like some proprietary extension to the HID protocol - the UPS expects the computer to send something that only the CyberPower software knows to send. Ah So... It does disconnect exactly every 20sec. I did check the cable, and moved it to each of the host receptacles. Also tried it on several different computers, with the exact same results (including FreeBSD 8.2) So this seems like a usb device originating issue. Once the usbhid-ups driver connects, the disconnect/reconnect cycle stops. In this light, the problem seems to be that the device may be temporarily unavailable at the moment the usbhid-ups driver attempts to connect, at boot time. ASIDE Maybe this is a relatively fixed, but unknown asyncronous delay at boot time. When this delay is favorable, so that the device is available when the driver checks, the connection is established, and nut starts successfully at system boot. When the delay is unfavorable, the device is in the middle of disconnect/reconnect when the driver checks and nut fails to connect and start. This would explain why some combinations of kernel, drivers, boot order, etc, just _seemed_ to work reliably. /ASIDE If this is correct, it seems the 'fix' would be to build a small delay, and retry, into the initial connection code of the usbhid-ups driver. Before giving up on finding the device. Is this practical? Thank you Again Charles and Arnaud! johnea ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
On 06/16/2011 10:51 AM, n...@johnea.net wrote: On 06/16/2011 04:15 AM, Charles Lepple wrote: Is it consistently disconnecting every 20 seconds? That almost sounds like some proprietary extension to the HID protocol - the UPS expects the computer to send something that only the CyberPower software knows to send. In this light, the problem seems to be that the device may be temporarily unavailable at the moment the usbhid-ups driver attempts to connect, at boot time. I'm in the lab now, I think I've confirmed this. If I move the upsd startup to before the system's dhcp, it always connects to the UPS at boot. If it's after the dhcp delay, then the UPS has dropped offline, and the nut startup fails. If this is correct, it seems the 'fix' would be to build a small delay, and retry, into the initial connection code of the usbhid-ups driver. Before giving up on finding the device. Is this practical? This startup retry would only need to affect the usbhid-ups CyberPower subdriver: - Using subdriver: CyberPower HID 0.3 Thank you Again Charles and Arnaud! johnea ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
On 06/15/2011 02:24 PM, n...@johnea.net wrote: - Does this seems to indicate the conflict of drivers you mentioned? usbtree data that may indicate driver conflict is the issue: The output of usbtree when the device is disconnecting: /: Bus 04.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M |_ Port 1: Dev 26, If 0, Prod=CP425HG, Class=HID, Drv=usbhid, 1.5M The output of usbtree once usbhid-ups has succesfully connected: /: Bus 04.Port 1: Dev 1, Class=root_hub, Drv=uhci_hcd/2p, 12M |_ Port 1: Dev 27, If 0, Prod=CP425HG, Class=HID, Drv=usbfs, 1.5M Is there a udev rule that can block the usbhid driver from connecting to the device? Thank You! johnea ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower usbhid-ups continuously disconnects/reconnects
Hi
2011/6/7 n...@johnea.net
Hello,
I've had this same model CyberPower connected to a linux server and a
freebsd server.
[root@sensor003 menon]# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
When the nut daemons start attempting to monitor the UPS, the device
begins a cycle of disconnecting and reconnecting every 20sec.
Running 'usbhid-ups -a nexups' manually, yields permissions issues:
[root@sensor003 menon]# usbhid-ups -a nexups
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
Using subdriver: CyberPower HID 0.3
libusb_get_report: could not claim interface 0: Device or resource busy
Got disconnected by another driver: Device or resource busy
this msg is typical of multiple driver instances running, and fighting to
get the hand on the device.
you can confirm this with an 'ls', and fix it by stopping / killing
everything, then starting the driver using upsdrvctl.
Can't initialize data from HID UPS
[root@sensor003 network-ups-tools]# ls -l /dev/bus/usb/003/
total 0
crw-rw-r-- 1 root root 189, 256 Jun 7 10:55 001
crw-rw 1 root nut 189, 270 Jun 7 11:58 015
There is a udev rule to set permissions on this device:
[root@sensor003 menon]# cat /etc/udev/rules.d/91-local.rules
# set permissions for CyberPower UPS -jea 2010-06-02
SUBSYSTEM==usb, ATTRS{idVendor}==0764, GROUP=nut, MODE=0660
there should already be a set of rules generated by NUT and named
52-nut-usbups.rules and located in /lib/udev/rules.d
The group and permissions show that this has been applied.
I'm not a linux-usb developer, and I don't quite get the depth of this,
but it seems the system hid driver is attaching to this device as it
enumerates, preventing the nut driver from attaching.
This device was finally attached before (nut 2.4) after applying the
patch mentioned here:
http://www.mail-archive.com/nut-upsuser@lists.alioth.debian.org/msg05550.html
This corrected for this low speed device not providing packets greater
than 8 bytes in length.
This patch didn't apply directly to the nut 2.6 source.
Can anyone confirm if this 8byte low speed device buffer size limit is
applied in 2.6?
2.6.1 has a smarter fix for this, since having a hard-coded 8 bytes length
caused regressions on some other devices.
cheers
Arnaud
--
Linux / Unix Expert RD - 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/
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
