[Nut-upsuser] [HCL] MGE Pulsar Evolution 1100 - not recognized by USB driver

[Charles Lepple]

On Dec 23, 2011, at 8:57 AM, Thomas Laus wrote:

>> On Dec 22, 2011, at 11:31 AM, nut at johnea.net wrote:
>> 
>> I agree - when trying to make tripplite_usb work on FreeBSD 6.x, I saw a lot
>> of weird problems due to the kernel requesting updates from the hardware far
>> more often than the NUT drivers would typically request them. The kernel
>> buffers would fill, and the packets would get misaligned. It was a mess. Might
>> not be as bad with usbhid-ups, but I think the upgrade is worthwhile for
>> long-stability of your USB devices.
>> 
>> johnea might have more up-to-date information on which devices nodes will need
>> their permissions changed such that NUT can access them while not running as
>> root. If not, I can boot my 8.x box and see what needs to be done.
>> 
> I can echo this advice concerning USB on OpenBSD as well,

Out of curiosity, which version of OpenBSD?

> even when using 
> another brand of UPS.  It seems that the USB drivers in NUT do not play well 
> with the expectations of the BSD kernel.  I ended up using the serial 
> connection for an Eaton 5115 because of buffer alignment issues.  This caused 
> my CPU to rapidly climb to 100 percent on the bcmxcp_usb task and only 
> killing the process restored sanity to my system.

Not to beat this to death, but I don't think there's much we can do on the NUT side if the BSD USB stack is taking an inherently packetized data link (where byte zero of a packet means something different than bytes 1-N) and blurring the boundaries between packets (for ugen, specifically). This only really works for streaming protocols such as USB printing.

Also, the old BSD stack seems unique in that it blindly honors the interrupt polling frequency for Interrupt IN endpoints, even when it is absurdly high - something which I have not seen in any other OS. This is what caused the buffer alignment issues with tripplite_usb and a Tripp-Lite OMNIVS1000. Had the NUT driver looped on reading from the kernel often enough to not allow the kernel buffers to fill, it would have also consumed most of the available CPU time.

The more common USB peripherals don't seem to have this problem since the USB stack has specialized drivers (e.g. mouse and keyboard) that can keep up with the higher interrupt frequency - and usually keyboard and mouse USB descriptors specify a reasonable interrupt polling frequency.

> All of the BSD's share some USB kernel code and it will take one of their 
> hackers to fix this mess.

The reworked USB stack in FreeBSD 8.x fixes this, as far as I can tell. I have not looked into 9.x, but it's really more that the FreeBSD USB stack needs to diffuse into the rest of the BSD family.