Hello. Recently virtual/libusb-{0,1}-r1 and related packages have gone stable. After libusb upgrade my UPS is not detected by nut anymore. Rebuilding nut doesn't help. If I downgrade back to virtual/libusb-{0,1}, then everything works fine again. This is the error message printed by `/etc/init.d/upsdrv start` command when run against libusb-r1: * Starting UPS drivers ... Network UPS Tools - UPS driver controller 2.6.5-Unversioned directory Network UPS Tools - Megatec/Q1 protocol USB driver 0.09 (2.6.5-Unversioned directory) No supported devices found. Please check your device availability with 'lsusb' and make sure you have an up-to-date version of NUT. If this does not help, try running the driver with at least 'subdriver', 'vendorid' and 'productid' options specified. Please refer to the man page for details about these options (man 8 blazer). Driver failed to start (exit status=1) Related part of nut log: Jan 5 03:32:22 Plasma upsd[2342]: listening on 127.0.0.1 port 3493 Jan 5 03:32:22 Plasma upsd[2342]: Can't connect to UPS [Ippon] (blazer_usb-Ippon): No such file or directory Jan 5 03:32:22 Plasma upsd[2343]: Startup successful Jan 5 03:32:22 Plasma upsmon[2359]: Startup successful Jan 5 03:32:22 Plasma upsd[2343]: User upsmaster@127.0.0.1 logged into UPS [Ippon] Jan 5 03:32:22 Plasma upsmon[2361]: Poll UPS [Ippon@localhost] failed - Driver not connected Jan 5 03:32:22 Plasma upsmon[2361]: Communications with UPS Ippon@localhost lost Jan 5 03:32:27 Plasma upsmon[2361]: Poll UPS [Ippon@localhost] failed - Driver not connected Jan 5 03:32:27 Plasma upsmon[2361]: UPS Ippon@localhost is unavailable If you need any additional info, I'll provide it. Reproducible: Always
Created attachment 367112 [details] emerge --info nut
Created attachment 367114 [details] ups.conf
1. Please try nutdrv_qx in nut-2.7.1. 2. If that still fails, can you test which variants of libusb are actually broken? Your test list should be: =dev-libs/libusb-compat-0.1.4 >=dev-libs/libusb-compat-0.1.5-r2 =dev-libs/libusb-1.0.9 =dev-libs/libusb-1.0.9-r2 dev-libs/libusbx 3. Once you narrow down which versions, please strace the start of the specific ups driver
(In reply to Robin Johnson from comment #3) > 1. Please try nutdrv_qx in nut-2.7.1. Both blazer_usb and nutdrv_qx drivers from nut-2.7.1 suffer from this issue.
(In reply to Robin Johnson from comment #3) > 2. > If that still fails, can you test which variants of libusb are actually > broken? > Your test list should be: > =dev-libs/libusb-compat-0.1.4 > >=dev-libs/libusb-compat-0.1.5-r2 > =dev-libs/libusb-1.0.9 > =dev-libs/libusb-1.0.9-r2 > dev-libs/libusbx These results are with nut-2.6.5-r1. 1. virtual/libusb-0 virtual/libusb-1-r1 dev-libs/libusb-compat-0.1.5 dev-libs/libusbx-1.0.17 Fails. 2. virtual/libusb-0 virtual/libusb-1-r1 dev-libs/libusb-compat-0.1.5 dev-libs/libusb-1.0.9-r2 Works. I was unable to test virtual/libusb-0-r1 together with virtual/libusb-1. virtual/libusb-0-r1 wants dev-libs/libusb-compat-0.1.5-r2, which wants virtual/libusb-1 with ABI_X86 USE flags and that is virtual/libusb-1-r1 only. It looks like the problem is in libusbx though.
peter: libusbx seems to break some of the NUT modules. At least blazer_usb and nutdrv_qx per this bug.
not sure if this is relevant in this bug. but upon upgrading to libusbx-1.0.17 each time I emerge world I now get a emerge: there are no ebuilds to satisfy ">=dev-libs/libusbx-1.0.16-r3:1[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]". I just put some info on the forum about this https://forums.gentoo.org/viewtopic-t-982238.html if this not relevant feel free to remove this comment
(In reply to jms from comment #7) > not sure if this is relevant in this bug. not even remotely.
Ping
Have you tried =dev-libs/libusb-1.0.18? Have you tried it with and without USE="udev"? Because dev-libs/libusbx is about to be lastrited from tree as it merged back to libusb since version 1.0.18. Plus the bug has very little information to go with, and the failure is driver (hardware) specific, so if you still have problems with 1.0.18, I'd go with the upstream mailing list, upstream bugzilla, maybe one of the upstream developers has the hardware to reproduce the bug and fix it.
(In reply to Samuli Suominen from comment #10) > Have you tried =dev-libs/libusb-1.0.18? Have you tried it with and without > USE="udev"? > Because dev-libs/libusbx is about to be lastrited from tree as it merged > back to libusb since version 1.0.18. > > Plus the bug has very little information to go with, and the failure is > driver (hardware) specific, so if you still have problems with 1.0.18, I'd > go with > the upstream mailing list, upstream bugzilla, maybe one of the upstream > developers has the hardware to reproduce the bug and fix it. I will test all cases you've suggested during the weekend when I will have more spare time.
(In reply to Samuli Suominen from comment #10) > Have you tried =dev-libs/libusb-1.0.18? Have you tried it with and without > USE="udev"? > Because dev-libs/libusbx is about to be lastrited from tree as it merged > back to libusb since version 1.0.18. > > Plus the bug has very little information to go with, and the failure is > driver (hardware) specific, so if you still have problems with 1.0.18, I'd > go with > the upstream mailing list, upstream bugzilla, maybe one of the upstream > developers has the hardware to reproduce the bug and fix it. Tested with sys-power/nut-2.6.5-r1 (latest stable to date): 1. virtual/libusb-0 virtual/libusb-1 dev-libs/libusb-compat-0.1.5 dev-libs/libusb-1.0.18[+udev] Fails. 2. virtual/libusb-0 virtual/libusb-1 dev-libs/libusb-compat-0.1.5 dev-libs/libusb-1.0.18[-udev] Works. Yes, I use old versions of virtual/libusb and libusb-compat that were removed from tree because of this very bug.
(In reply to Coacher from comment #12) > Tested with sys-power/nut-2.6.5-r1 (latest stable to date): > > 1. > virtual/libusb-0 > virtual/libusb-1 > dev-libs/libusb-compat-0.1.5 > dev-libs/libusb-1.0.18[+udev] > > Fails. > > 2. > virtual/libusb-0 > virtual/libusb-1 > dev-libs/libusb-compat-0.1.5 > dev-libs/libusb-1.0.18[-udev] > > Works. Same results with sys-power/nut-2.7.1.
feel free to set USE="-udev" meanwhile and upgrade, it's optional flag for libusb, I don't know of anything *requiring* it (yet)
(In reply to Samuli Suominen from comment #14) > feel free to set USE="-udev" meanwhile and upgrade, it's optional flag for > libusb, I don't know of anything *requiring* it (yet) Yes, I already did this. Thanks.
Additional note: though blazer_usb starts and works with libusb-1.0.18 it is very unstable. I experience driver crashes every 2-3 days, while with libusb-1.0.9 driver worked for months. I am aware this is not Gentoo issue, I've posted this as a notice for other Gentoo users who may suffer from this bug.
I'm the libusb.org maintainer, who released libusb-1.0.9. (In reply to Coacher from comment #16) > Additional note: though blazer_usb starts and works with libusb-1.0.18 it is > very unstable. I experience driver crashes every 2-3 days, while with > libusb-1.0.9 driver worked for months. I'm not too surprised. Between libusb-1.0.9 and 1.0.18 the libusbx developers took over the libusb sourceforge project and simply released the libusbx code as libusb. > I am aware this is not Gentoo issue, I've posted this as a notice for other > Gentoo users who may suffer from this bug. I do think it would be a good idea for Gentoo to have libusb-1.0.9 be the only stable version, since it does not have several of the libusbx issues. See also bug #503404.
Unfortunately, sys-power/nut-2.7.1 has the same stability issues with libusb-1.0.18 as 2.6.5-r1.
Another note: today was a power outage and the driver died as soon as UPS switched to battery. libusb-1.0.18 renders nut completely useless. This is with nut-2.7.1. I'll create upstream bug on this matter soon.
