On Sat, Mar 6, 2010 at 3:41 PM, Arjen de Korte <[email protected]> wrote: > Citeren Charles Lepple <[email protected]>: > >> 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 _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
