[Nut-upsdev] [Nut-upsuser] Getting 'Data stale' error with bcmxcp_usb for a PowerWare 5115 on OSX

Charles Lepple clepple at gmail.com
Sun Mar 7 01:20:58 UTC 2010


On Sat, Mar 6, 2010 at 3:41 PM, Arjen de Korte <nut+devel at de-korte.org> wrote:
> Citeren Charles Lepple <clepple at gmail.com>:
>
>> A while back, NUT opened the USB device, forked, and used that
>> descriptor in the child process. That breaks in OS X because the USB
>> connection is per-process.
>
> In that case, we're toast. :-(
>
>> Currently, if the debug level is zero, we
>> go into the background before opening the USB device.
>
> No, we don't (see 'drivers/main.c'). Backgrounding is one of the last things
> we do (line 618), before starting the main loop. The USB device has been
> opened long before that in upsdrv_initups (line 577).

Wow, I totally misread that code.

>> I admit I
>> haven't done physical device testing with 2.4.3 on OS X yet (I spent
>> too much time messing with FreeBSD for the last release), but I don't
>> remember any other recent architectural changes which could cause
>> problems like that.
>
> I guess it all depends if the driver is able to detect it can no longer talk
> to the UPS and reconnects. Usually, I would expect that after a couple of
> failed attempts to read data, the UPS would assume the connection is lost
> and reconnect (at least, that is what most USB drivers do I'm familiar
> with). Apparently, this isn't working here.

Hmm. All of the USB UPSes that I have tested will reconnect, so I
guess that's what makes them work here.

> Since running the driver in debug mode effectively works around the problem,
> we probably need to add some upslogx() lines strategically tp see in the
> syslog what is going on.

We might also be able to get some information from one of the dtrace
commands - "dtruss" is meant to be a dtrace implementation of truss,
which looks an awful lot like strace.

-- 
- Charles Lepple



More information about the Nut-upsdev mailing list