On Wed, 22 Aug 2007, Charles Lepple wrote: > NUT drivers poll the UPS every so often, which works fine on systems > where a single libusb call results in a single USB transaction. In > FreeBSD (and probably other BSD systems as well), interrupt transfers > are scheduled periodically, even if the calling program is not > requesting interrupt transfers at the same rate.
I had a look through the USB code and it seems that ugen uses the default value which means that it obtains the value from the end point descriptor. > What I saw with tripplite_usb (where the USB descriptor for the > device tells the OS to poll 10-100 times a second) is that the driver > does not poll frequently enough, and an interrupt transfer buffer > fills up in the OS. Due to the way that libusb and the kernel USB > stack interact, this could cause the symptoms you are seeing. Hmm, which buffer? It would be nice if it could recover gracefully from this situation though (since a number of things could cause missed interrupts anyway) > I don't know of a good way to debug this. It seems like a problem in > the kernel, but it's hard to isolate it with a driver as complex as > usbhid-ups. Yes :( The USB stack is poorly documented too. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser