On Jan 2, 2015, at 3:33 PM, Mike Raath <raathm at gmail.com> wrote:> Sorry, I messed up my reply a bit. > > The output of the lsusb command is the same before and after the data goes stale. > > $ lsusb -d 0665: > Bus 002 Device 005: ID 0665:5161 Cypress Semiconductor USB to Serial >OK. That usually means that the VM kernel doesn't see that the device is disconnecting. You can check dmesg to be sure, but the Device numbers usually increment the next time a USB device is plugged in. Not sure how ESXi hands off the USB devices to the VMs, but is there a way to verify that other VMs are not seeing the UPS as well? Even simply probing the device (a la modemtools) will cause problems, especially if the USB-to-serial converter usually shows up as /dev/ttyUSB0 before NUT drivers start.> And the output of the /lib/nut/nutdrv_qx -a apollo-ups -DD 2>&1 command is the same as in the previous attachment. I truncated the "before" log because it just carried on with the same output after the broadcast notification that the UPS became unavailable (at 214.883342).Hmm, that's odd. I forgot to mention: be sure that there are no existing drivers running ('sudo killall blazer_usb' and 'sudo killall nutdrv_qx') before starting the driver in debug mode. Can you run it again with three "-D" flags, and let it go past the point where upsd complains? The third "-D" will show all read and write results, which should definitely be different when problems arise.> On 2 January 2015 at 22:14, Mike Raath <raathm at gmail.com> wrote: > Ok - before stale data: > > After stale data: > $ lsusb -d 0665: > Bus 002 Device 004: ID 0665:5161 Cypress Semiconductor USB to Serial > > > After stale data: > > > And the gzipped log attached: > > > > On 2 January 2015 at 21:56, Charles Lepple <clepple at gmail.com> wrote: > On Jan 2, 2015, at 2:43 PM, Mike Raath <raathm at gmail.com> wrote: > >> Not sure what other logs I can provide to try to troubleshoot this? >> > > > Two things: > > - the output of 'lsusb -d 0665:' before and after the 'stale data' warning > - the output of '/lib/nut/nutdrv_qx -a apollo-ups -DD 2>&1 | tee /tmp/nutdrv_qx.log' > > (Please gzip nutdrv_qx.log before sending it, thanks.) > > -- > Charles Lepple > clepple at gmail > > > > > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuserA: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150102/31e3a31a/attachment-0001.html>
(sorry about the top-posting) I did a killall on blazer_usb and nutdrv_qx, then did a lsusb, got the following: $ lsusb -d 0665: Bus 002 Device 005: ID 0665:5161 Cypress Semiconductor USB to Serial Then I started the driver in DDD mode, log attached, beyond the point where communication fails (591.465153). Lastly, I did the lsusb again and got this: $ lsusb -d 0665: Bus 002 Device 005: ID 0665:5161 Cypress Semiconductor USB to Serial Regarding how ESXi handles devices, I don't have a USB adapter in any of the other VMs, but maybe something is going on in the ESXi controller itself. I checked in /dev on the host and this is all there is. Maybe usbpassthrough is something I should look at? I'll do some reading. lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0101* -> *char/vmkdriver/usb0101* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0201* -> *char/vmkdriver/usb0201* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0202* -> *char/vmkdriver/usb0202* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0301* -> *char/vmkdriver/usb0301* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0401* -> *char/vmkdriver/usb0401* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0408* -> *char/vmkdriver/usb0408* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0501* -> *char/vmkdriver/usb0501* lrwxrwxrwx 1 root root 22 Jan 2 21:23 *usb0601* -> *char/vmkdriver/usb0601* lrwxrwxrwx 1 root root 25 Jan 2 21:23 *usbdevices* -> *char/vmkdriver/usbdevices* lrwxrwxrwx 1 root root 29 Jan 2 21:23 *usbpassthrough* -> *char/vmkdriver/usbpassthrough* # lsusb Bus 04 Device 08: ID 0665:5161 Cypress Semiconductor USB to Serial Bus 04 Device 01: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 06 Device 01: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 05 Device 01: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 02 Device 02: ID 8644:800b Bus 02 Device 01: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 03 Device 01: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 01 Device 01: ID 1d6b:0002 Linux Foundation 2.0 root hub -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150102/6861088f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: nutdr_qx-txt.tar.gz Type: application/x-gzip Size: 10948 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150102/6861088f/attachment.bin>
hyouko at gmail.com
2015-Jan-03 00:45 UTC
[Nut-upsuser] Data stale error after short while
Hello there.
I looked quickly at the logs:
1. this UPS seems to have a somewhat strange implementation of the
megatec protocol (or maybe it's just the usb-to-serial thing): 'F'
reply begins with '!' - it should be a '#' -, is it always like
that?
2. after some time the expected first character ('(') of the
'Q1'
reply is replaced by a '$' but, alas, there was a bug in early
versions of nutdrv_qx that prevented the driver from getting a fresh
reply from the UPS under some circumstances, so probably it gets stuck
using always the same malformed reply.
If possible, upgrade to the current git head, maybe after some replies
with the first character swapped the UPS get back to the usual
behaviour.
On Jan 2, 2015, at 4:27 PM, Mike Raath <raathm at gmail.com> wrote:> Maybe usbpassthrough is something I should look at? I'll do some reading.You may have found this already, but this (plus the followup KB item #1021345) seems to imply that you can bind the USB-to-serial adapter to the NUT VM: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022290 You should be able to do "USB 2.0/1.1 Host-Connected" with that cable. In fact, if the host supports USB 3.0, it may help to move the converter to a non-3.0 port. This is in addition to the comments from Dan (hyouko at gmail) regarding the start character. -- Charles Lepple clepple at gmail