2008/1/26, Arjen de Korte <[EMAIL PROTECTED]>: > [...] > > >> The output of lsusb and ls -lR /dev/bus/usb is the same for the two > >> versions. > > > > thanks for your quick feedback Sven. > > > > @Carlos: there is a clear regression here. > > Poor Carlos, he is getting all the flak, while the problem is in the > megatec_usb.c... :-)
right, sorry for this Carlos! I still have a hard link on the pattern megatec <=> Carlos, and I've not updated it for the "_usb" version ;-) @Carlos: can you be the general interface for megatec, both serial and usb? since you're the NUT reference for megatec... > > I'm thinking of a recent timeout problem (was 1000 instead of 5000). > > Do you see something? > > Increasing the timeout value here, is the worst fix possible. Under no > circumstance should drivers hang around that long in upsdrv_updateinfo(). that is the case for usbhid-ups: the various functions that accept a TIMEOUT use 4 sec... And 1 second can be too short. > The problem here is that none of the subdrivers in 'megatec_usb.c' in > nut-2.2.1 handle the return codes from the libusb functions properly. By > sending the EAGAIN error code, they clearly indicate that the command > needs to be retried, instead of declaring it a failure. This might be > handled a little better from r1211 onwards, which added a the possibility > to reconnect. I'm not sure if reconnecting is the proper way to handle > this though. It might be better to just retry the command the next time. has this been backported to Testing? Arnaud -- Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
