reopen 322901 thanks Salut JM,
2007/1/12, jeanmichel <[EMAIL PROTECTED]>:
Package: nut-usb Version: 2.0.4-3 Followup-For: Bug #322901 With an ellipse 600: Jan 11 16:09:01 localhost /USR/SBIN/CRON[28115]: (root) CMD ( [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm) Jan 11 16:14:11 localhost kernel: usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 255 ret -110 Jan 11 16:14:12 localhost kernel: usb 1-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 255 ret -110 Jan 11 16:14:12 localhost upsd[25264]: Data for UPS [usb] is stale - check driver Jan 11 16:14:13 localhost upsmon[25267]: Poll UPS [EMAIL PROTECTED] failed - Data stale Jan 11 16:14:13 localhost upsmon[25267]: Communications with UPS [EMAIL PROTECTED] lost Jan 11 16:14:18 localhost upsmon[25267]: Poll UPS [EMAIL PROTECTED] failed - Data stale Jan 11 16:14:20 localhost upsd[25264]: UPS [usb] data is no longer stale Jan 11 16:14:23 localhost upsmon[25267]: Communications with UPS [EMAIL PROTECTED] established
how often does it happen? This can help me in hunting a bit more that bug, but as stated before, I don't think I'll be able to completely remove the "usbfs", but only the stale/restored communication. FYI, this is (or should be) a temporary "deny of service" from the UPS. This can happen when the unit is too heavily loaded (ie quering too much the data, while the unit is auto testing its battery). Note that lowering the driver polling frequency should reduce (maybe suppress) this. See newhidups -h -> pollfreq for more info. Finally, I've reopened the bug as a reminder. thanks for the report, Arnaud -- Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ OpenSource Developer - http://arnaud.quette.free.fr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
