On Tue, Mar 30, 2010 at 4:36 PM, Wallis, Chase Civ USAF AFMC 519 SMXS/MXDEA <[email protected]> wrote: > Stack: > Read > Usb_do_io > Usb_interrupt_read > Usb_interrupt_read > Libusb_get_interrupt > Send_cmd > Upsdrv_updateinfo > Main > _start
usb_interrupt_read() is in libusb (unlike the mis-named libusb_get_interrupt()... argh...) so I don't really know what we're doing wrong. Anything above that point is OS-specific. [Fedora info] >> More info and log messages can be found here: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=575875 >> >> if you are interested in any info, let me know and I'll ask the > reporter. > > It may be similar/same. I think it may be too early to tell. Thoughts? > Suggestions? Probably too early to tell, but my hunch is that it is similar. NUT usually can't cause the kernel to go haywire by itself - the drivers usually have a reasonable polling speed, and the kernel should take care of any timeouts or unexpected responses from the hardware. -- - Charles Lepple _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
