[was: Re: [Nut-upsuser] FreeBSD rc.d scripts or shutdown howto?] On 8/22/07, Daniel O'Connor <doconnor at gsoft.com.au> wrote:> On Wed, 22 Aug 2007, Bryan wrote: > > The trouble I'm now having is that UPS communication just stops for > > no apparent reason. Data goes stale and I get the broadcasts about > > the UPS being unavailable. upsc tells of a similar fate. *sigh* > > Yes, AFAIK this is because you're using a USB UPS. I've never been able > to reliably talk to one on FreeBSD.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. 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. 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. -- - Charles Lepple
On 23/08/07, Charles Lepple <clepple at gmail.com> wrote:> 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.I see what you're saying -- and I can see how difficult that would be to track down. The symptoms I'm continuing to see certainly could be a product of that same behaviour you mention. At this stage, I think I've reached the end of the road for USB UPSs on FBSD. For the time and effort put into this thing, I could have purchased a much larger RS-232 based UPS. Such is life. Thanks for all your help -- it made a big difference. Bryan.
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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20070823/590f109a/attachment.pgp