[Nut-upsuser] Windows 2.6.0-1 usbhid-ups driver infinite loop on USB disconnect

[Arnaud Quette]

2011/6/29 Frédéric Bohé <fredericbohe at 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.net at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20110629/10fb7bbd/attachment.html>