Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
Citeren Charles Lepple clep...@gmail.com: Arjen: do we actually have any cases of reports larger than 8 bytes? Yes. At least the MGE Evolution series uses reports that are larger than 8 bytes. If so, should we mark this as a quirk for CyberPower devices? Well, I still don't understand why we can't read with an arbitrary buffer length in the libusb call in the first place. This should be handled by the library (not the application). Also, it seems like we need to distinguish between returning 0 and 0 from the libusb call. Currently, we are reading errno when a zero-length packet is being read. This too is broken. If we attempt to read a report and libusb can't return any data, it should at least give us a hint why. I really feel that this should be handled by the library, not NUT. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
2011/3/17 Arjen de Korte nut+us...@de-korte.org Citeren Charles Lepple clep...@gmail.com: Arjen: do we actually have any cases of reports larger than 8 bytes? Yes. At least the MGE Evolution series uses reports that are larger than 8 bytes. some Eaton and Dell models too If so, should we mark this as a quirk for CyberPower devices? Well, I still don't understand why we can't read with an arbitrary buffer length in the libusb call in the first place. This should be handled by the library (not the application). Also, it seems like we need to distinguish between returning 0 and 0 from the libusb call. Currently, we are reading errno when a zero-length packet is being read. This too is broken. If we attempt to read a report and libusb can't return any data, it should at least give us a hint why. I really feel that this should be handled by the library, not NUT. seconded. I've not had a look at libusb-1 to see if the situation has improved, but I hope so... 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/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
Citeren Charles Lepple clep...@gmail.com: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each operation not permitted error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without -u root)? Attached. Looks like Ubuntu fixed 2.4.3 here: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/572262 That was committed to NUT here: http://trac.networkupstools.org/projects/nut/changeset/2407 This breaks reading larger reports, so it was reverted: http://trac.networkupstools.org/projects/nut/changeset/2719 This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 All of the above are irrelevant here. The driver runs fine when started as root, so this must be a permissions problem. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On 3/17/2011 12:17, Arjen de Korte wrote: This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 All of the above are irrelevant here. The driver runs fine when started as root, so this must be a permissions problem. The original problem that r2407 addressed (which I also experienced) manifested similarly, in that running as root it would work, running as non-root it would not. I don't know enough about usb/libusb to have any clue why that would be, but it was. So I tried applying the diff from r2893 to the Debian nut 2.6.0-1 source package and building that, and lo and behold it now works as non-root! Also, when running as root before, it spat out a lot of warnings while fetching the reports, now it spits out none. While I didn't really understand the warnings before, I'd assume that not generating them is a sign of things working better. Given that there doesn't seem to have been a new release of libusb0 in something like four or five years, then if this really does need to be fixed at the libusb level, I suspect the first thing that will have to happen is nut moving to libusb1. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On 3/15/2011 6:22, Charles Lepple wrote: On Mar 14, 2011, at 1:20 AM, Cheetah wrote: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each operation not permitted error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without -u root)? Attached. Also, what architecture is this running on? x86_64, Intel X58 chipset, core i7 series processor. usbhid-ups.strace.gz Description: GNU Zip compressed data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On Wed, Mar 16, 2011 at 5:02 PM, Cheetah fast...@gmail.com wrote: On 3/15/2011 6:22, Charles Lepple wrote: On Mar 14, 2011, at 1:20 AM, Cheetah wrote: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each operation not permitted error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without -u root)? Attached. Looks like Ubuntu fixed 2.4.3 here: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/572262 That was committed to NUT here: http://trac.networkupstools.org/projects/nut/changeset/2407 This breaks reading larger reports, so it was reverted: http://trac.networkupstools.org/projects/nut/changeset/2719 This patch (committed after 2.6.0 was released) claims to restore 2.4.1 behavior: http://trac.networkupstools.org/projects/nut/changeset/2893 Arjen: do we actually have any cases of reports larger than 8 bytes? If so, should we mark this as a quirk for CyberPower devices? Also, it seems like we need to distinguish between returning 0 and 0 from the libusb call. Currently, we are reading errno when a zero-length packet is being read. -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Problems with usbhid-ups and CyberPower CP1500 on 2.6.0
On Mar 14, 2011, at 1:20 AM, Cheetah wrote: If I run it under strace, the ioctls on the /dev/bus/usb file descriptor preceeding each operation not permitted error return 0, not an error code such as EPERM. That seems strange. Would you please compress and send the strace output (without -u root)? Also, what architecture is this running on? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser