Re: [Nut-upsuser] tcgetattr: Inappropriate ioctl for device
Citeren Martin Ivanov tra...@abv.bg: root@alhana:/etc/nut# /etc/rc.d/rc.ups start Network UPS Tools - UPS driver controller 2.6.0 Network UPS Tools - Generic contact-closure UPS driver 1.36 (2.6.0) UPS type: Repoteck RPT-800A, RPT-162A tcgetattr: Inappropriate ioctl for device Driver failed to start (exit status=1) Does this mean that the driver is not supported or am I missing something? The genericups driver is for serial devices only. Only if the UPS has a supported USB to serial converter on board that is recognized by the kernel, you can use it. But in that case, you'd need to configure the /dev/ttyUSBx port that is created, not the USB port. 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/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows 2.6.0-1 usbhid-ups driver infinite loop on USB disconnect
Hello David, First, thanks for this post. The Windows port is still in beta stage and this kind of post if very useful. On Tue, 2011-06-28 at 20:54 -0400, David Bolen wrote: David Bolen db3l@gmail.com writes: Attached below is an excerpt of debugging output from usbhid-ups. It would appear that the interrupt and query failures have reasonably appropriate errors, so maybe it's just a difference in how such errors reflect under Windows vs. *nix. Following up on my own note, I think I have a theory on what is happening, but am having trouble compiling to test a change as while I have an pre-existing Mingw/MSYS toolchain, it doesn't have a full autoconf toolchain yet. If anyone might have a pre-existing configure script for Win32, that would help jump start things as I could configure from there. Setting up the build environnent in Windows is kind of complex. I will send you my configure file if it can help you. Don't hesitate to ask if you are still stuck. I think I've run into two items. The first is that the errors from checking the interrupt pipe in upsdrv_updateinfo aren't actually checked for cases where they could identify a disconnected UPS, so it just assumes no information and continues. That's not Win32 specific. I'm not quite sure why it loops so quickly, as opposed to the top level polltime, but perhaps the state of the driver connection is such that it immediately satisfies the WaitForMultipleObjects call in the Win32 version of dstate_poll_fds. It's just a silly bug. The timeout of WaitForMultipleObject is supposed to be in milliseconds but it is passed in seconds. Anyway, normally it looks like that would be short-lived anyway since the periodic full poll would detect the disconnect a modest time later. Here I think I run into an assumption in the libhid code that errno always identifies all errors, while in the case of a win32 failure inside of libusb-win32, it's only the result code of the function calls that reflect the error, not errno. So USB I/O level errors while polling are getting hidden. Another bug. errno has to be filled with the result of GetLastError() to be really useful. After shrinking the poll time and letting things run a bit after a cable disconnect, I got a few other errors (from libusb_get_report) interleaved such as: 5.843750 Got 0 HID objects... 5.843750 Quick update... 5.859375 upsdrv_updateinfo... 5.859375 libusb_get_interrupt: libusb0-dll:err [submit_async] submitting request failed, win error: The device does not recognize the command. 5.859375 Got 0 HID objects... 5.859375 Quick update... 5.859375 libusb_get_report: libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command. 5.859375 Can't retrieve Report 16: No error 5.859375 libusb_get_report: libusb0-dll:err [control_msg] sending control message failed, win error: The device does not recognize the command. 5.859375 Can't retrieve Report 15: No error 5.859375 upsdrv_updateinfo... 5.859375 libusb_get_interrupt: libusb0-dll:err [submit_async] submitting request failed, win error: The device does not recognize the command. From looking at the libusb-win32 source, this would be the result of a Win32 ERROR_BAD_COMMAND code which is turned into a -EIO result for the usb_control_message call. But in this case, it's only the result that has the error, as it's a translation from the Windows internal error and not from any original errno value. It appears that the NUT libusb.c module passes the return code on fine, but then it's suppressed with libhid.c (refresh_report_buffer), and eventually HIDGetDataValue, who just gets a generic -1 code, assumes it can pass along -errno to the usbhid-ups driver, which at that point has no error (yielding the No error in the Can't retrieve Report message. It seems like adjusting functions along the path to all return the function result code as opposed to just -1 would work but also feels like a riskier change. I'm wondering if perhaps just making the lower level libusb entry points (probably just #if WIN32) assign the result code of the libusb-win32 driver calls to errno to ensure it represents the failures would be cleaner and help obscure the Windows differences? I guess that managing correctly errno with GetLasterror should be enough. -- David PS: In reviewing the libusb-win32 source it also looks like in some cases it can return either EINVAL or ENOMEM, neither of which are checked for in the error checking path for usbhid-ups, so probably could get added, if only to the WIN32 block. Indeed, after setting errno correctly using GetLastError(), I add EINVAL as a disconnection cause and it seems to work now. Adding ENOMEM might be useful too. May I privately mail you a link to a replacement driver with those fixes for
Re: [Nut-upsuser] Windows 2.6.0-1 usbhid-ups driver infinite loop on USB disconnect
2011/6/29 Frédéric Bohé fredericb...@eaton.com Hello David, First, thanks for this post. The Windows port is still in beta stage and this kind of post if very useful. On Tue, 2011-06-28 at 20:54 -0400, David Bolen wrote: David Bolen db3l@gmail.com writes: Attached below is an excerpt of debugging output from usbhid-ups. It would appear that the interrupt and query failures have reasonably appropriate errors, so maybe it's just a difference in how such errors reflect under Windows vs. *nix. Following up on my own note, I think I have a theory on what is happening, but am having trouble compiling to test a change as while I have an pre-existing Mingw/MSYS toolchain, it doesn't have a full autoconf toolchain yet. If anyone might have a pre-existing configure script for Win32, that would help jump start things as I could configure from there. Setting up the build environnent in Windows is kind of complex. I will send you my configure file if it can help you. Don't hesitate to ask if you are still stuck. I think I've run into two items. The first is that the errors from checking the interrupt pipe in upsdrv_updateinfo aren't actually checked for cases where they could identify a disconnected UPS, so it just assumes no information and continues. That's not Win32 specific. I'm not quite sure why it loops so quickly, as opposed to the top level polltime, but perhaps the state of the driver connection is such that it immediately satisfies the WaitForMultipleObjects call in the Win32 version of dstate_poll_fds. It's just a silly bug. The timeout of WaitForMultipleObject is supposed to be in milliseconds but it is passed in seconds. Anyway, normally it looks like that would be short-lived anyway since the periodic full poll would detect the disconnect a modest time later. Here I think I run into an assumption in the libhid code that errno always identifies all errors, while in the case of a win32 failure inside of libusb-win32, it's only the result code of the function calls that reflect the error, not errno. So USB I/O level errors while polling are getting hidden. Another bug. errno has to be filled with the result of GetLastError() to be really useful. wasn't it suppose to be already the case? along with the equivalent winsock WSAGetLastError() where appropriate? otherwise, this should indeed fix tons of issues, as it did years ago on Linux... cheers, Arno ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows 2.6.0-1 usbhid-ups driver infinite loop on USB disconnect
Arnaud Quette aquette@gmail.com writes: 2011/6/29 Frédéric Bohé fredericb...@eaton.com Another bug. errno has to be filled with the result of GetLastError() to be really useful. wasn't it suppose to be already the case? along with the equivalent winsock WSAGetLastError() where appropriate? otherwise, this should indeed fix tons of issues, as it did years ago on Linux... Not sure if it was supposed to be the case, but the libusb module wasn't doing it at the moment. I've finally been able to work up a build environment, and setting errno to the libusb function result (well, its negative) does appear to resolve the issue. And Frédéric's other fix to the WaitForMultipleObjects in dstate.c does take care of the otherwise tight polling loop. Note that in this case you don't want to set errno directly to GetLastError() since libusb is already doing a translation between the Win32 value into an more standard errno E* value for the purpose of the function result. The raw GetLastError() wouldn't be sensible for the higher level code expecting errno values - would it ever be? Not sure about any WSAGetLastError but there's no socket related actions in this code path, so that could be for other use cases. -- David ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Belkin F6C1200-UNV on Ubuntu 11.04
On Sat, Jun 25, 2011 at 7:15 PM, Martin Ewing martin.s.ew...@gmail.com wrote: On Sat, Jun 25, 2011 at 5:48 PM, Charles Lepple clep...@gmail.com wrote: On Jun 24, 2011, at 8:50 PM, Martin Ewing wrote: I had been using NUT's Ubuntu package (64 bit) with no problems until upgrading to Ubuntu 11.04. What was the previous NUT package version? ^^^ Previous question still stands. Is there an upgrade log (/var/log/dpkg.log or similar) which mentions the old .deb version? If I have time later this weekend, I'll swap out that UPS for one which uses the usbhid-ups driver and see if I can reproduce the problem. I seem to have hardware problems with the UPS which is compatible with that driver, so I can't test with usbhid-ups. Device: $ ls -l /dev/bus/usb/006/001 crw-rw-r-- 1 root root 189, 640 2011-06-24 18:29 /dev/bus/usb/006/001 Not in group nut. I think that part might be a bug in Ubuntu's combination of NUT and udev (at some point, udev changed the way it matches USB devices). Are there any messages from udev in syslog? But I tried one more thing. I powered down the UPS completely and restarted everything. (I wondered if the Belkin's USB was hung up.) Now, I get something different: $ sudo /lib/nut/usbhid-ups -a mybelkin Network UPS Tools - Generic HID driver 0.35 (2.6.0) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 libusb_get_report: error sending control message: Operation not permitted libusb_get_report: error sending control message: Operation not permitted Can't initialize data from HID UPS and $ ls -l /dev/usb total 0 crw--- 1 root root 180, 96 2011-06-25 18:58 hiddev0 crw-rw 1 root lp 180, 0 2011-06-25 18:58 lp0 martin@gimli:~$ ls -l /dev/bus/usb/006/001 crw-rw-r-- 1 root root 189, 640 2011-06-25 18:58 /dev/bus/usb/006/001 If I try -u root $ sudo /lib/nut/usbhid-ups -a mybelkin -u root Network UPS Tools - Generic HID driver 0.35 (2.6.0) USB communication driver 0.31 Using subdriver: Belkin HID 0.12 libusb_get_report: No error libusb_get_report: No error libusb_get_report: No error libusb_get_report: No error libusb_get_report: No error libusb_get_report: No error libusb_get_report: No error ... This was fixed in v2.6.1, or more specifically, in r2893: http://trac.networkupstools.org/projects/nut/changeset/2893 Can you file a bug? A similar problem was filed here: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/572262 and here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583371 -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
