2009/7/17 Greg Vickers <daehe...@optusnet.com.au> > Hi Arnaud, >
Hey Greg, > > > Arnaud Quette <aquette....@gmail.com> wrote: > > > > Hi Greg > > > > first, a thank to Kjell too... > > > > 2009/7/12 Greg Vickers <daehe...@optusnet.com.au> > > > > > Hi Kjell, > > > > > > > > > Kjell Claesson wrote: > > > > > >> Hi all, > > >>> > > >> Hi Greg, > > >> > > >> I've got a Powerware 5110 UPS that I'm trying to set up with nut in > > >>> Ubuntu. I've installed nut and configured the first two files: > > >>> > > >>> $ cat /etc/nut/nut.conf > > >>> MODE=standalone > > >>> $ cat /etc/nut/ups.conf > > >>> [pw5110] > > >>> driver = bcmxcp_usb > > >>> port = auto > > >>> # port = /dev/bus/usb/002/002 > > >>> > > >> Yes the port should be auto. > > >> And if you use the latest libusb you should have a device > > >> at /dev/bus/usb/002/002 that you have found. > > >> > > >> > > >>> When I try to test this configuration with the following command: > > >>> $ sudo upsdrvctl start pw5110 > > >>> Network UPS Tools - UPS driver controller 2.4.1 > > >>> Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) > > >>> USB communication subdriver 0.17 > > >>> Can't set POWERWARE USB configuration > > >>> Unable to find POWERWARE UPS device on USB bus > > >>> > > >>> > > >> To make a real test that it read the usb you can do the following. > > >> Set libusb debug to 3. > > >> sudo export LIBUSB_DEBUG=3 > > >> > > >> Then run the driver in debug (not by upsdrvctl). > > >> sudo /path/to/bcmxcp_usb -DD -u -a pw5110 > > >> > > >> Now it should spit out some info. You end it by ctrl-c. > > >> > > >> Report back and we can have a look. > > >> > > >> We may have a bug here, but it is not confirmed as our tests > > >> does not reveal it. > > >> > > > > > > After leaving my Ubuntu host overnight, I've turned it on and the nut > > > daemon was running when I tried the above check. I stopped that > > daemon and > > > the above test worked just fine! I didn't change anything and now > > it's > > > working just fine. > > > > > > Thank you for the information about the debug test! All OK now! :) > > > > well, ok now, but there is still something under the hood! > > my guess is that the udev update change introduced by Scott James > > doesn't fully refresh the udev rights. > > I've not taken the time to validate it though, so mea culpa. > > the result is basically that if you don't unplug/replug your device or > > reboot your system after nut installation, the udev rule is not applied. > > I did try unplugging and replugging the USB cable the UPS was attached by, > and still couldn't contact the UPS correctly. I have also had trouble on > this system with the IR receiver on my TV tuner card not reappearing on a > reboot, I have to do a shutdown and turn the host back on to get the IR > receiver device to reappear. I didn't diagnose this IR receiver problem > until after that night, so I suspect that this may have impacted the UPS > communication as well. > you're running Jaunty, right? what perms do you have on your device (when it was not nut)? a simple test (I've just replayed here) is to remove nut (don't purge, you'll keep your config), unplug your UPS USB cord, plug it back and check the device, ie /dev/bus/usb/XXX/YYY where XXX is the Bus number and YYY the Device number, as given by lsusb. here it was vboxusers (due to VirtualBox installed here). > However, now when I do a reboot, the UPS is detected just fine - go figure. > > At one point I was suspicious that the udev rule wasn't being run, and > tried copying it into /etc/udev/rules.d, and un/re-plugging the UPS, but to > no avail. > /etc/udev/rules.d is now for local rules (ie the ones created by the user/sysadmin). the distro rules now sits in /lib/udev/rules.d... > > I'll try to check that tomorrow, and make some more progress on 2.4.1-4, > > which will be a major Debian update. > ok, I've validated that the faulty bits is the new call to udevadm (thanks Scott James for this change!) udevadm trigger --action=change that is not sufficient to refresh (coldplug) the device perms without the before mentioned system reboot or device unplug/replug... the problem is that the previous call (udevadm trigger --subsystem-match=usb_device) will refresh all USB devices, resulting in a kind of reset. I've gotta check for a more suitable solution. cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops 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