[Nut-upsuser] "Communications with UPS advice at localhost lost" when using an other USB device

[Charles Lepple]

On Nov 25, 2014, at 8:17 PM, Victor Porton <porton at narod.ru> wrote:

> Well, also below in dmesg:
> 
> [  190.249219] usb 3-1.3: usbfs: USBDEVFS_CONTROL failed cmd blazer_usb rqt 33 rq 9 len 8 ret -110

-110 is -ETIMEDOUT.

> 26.11.2014, 03:05, "Victor Porton" <porton at narod.ru>:
>> A fragment of dmesg output (here idVendor=0665, idProduct=5161 is the UPS; the webcam is idVendor=17a1, idProduct=0128):
>> 
...
>> [    1.521492] usb 3-1.3: new low-speed USB device number 3 using ehci-pci
>> [    1.619257] usb 3-1.3: New USB device found, idVendor=0665, idProduct=5161
...
>> [    1.693685] usb 3-1.4: new full-speed USB device number 4 using ehci-pci
>> [    1.786441] usb 3-1.4: New USB device found, idVendor=17a1, idProduct=0128

If I read this correctly, you have a low-speed (1.5 Mbit/sec) UPS on the same bus as a full-speed (12 Mbit/sec) webcam. These days, I would expect a webcam to operate at high speed (480 MBit/sec). I don't know how the Linux kernel schedules USB requests, but it is entirely possible that under these conditions, Cheese is saturating the bus.

Can you plug either of the two devices into different ports?

>>>  Shall we consider this very message as a bug report, or should I report a bug otherwise somewhere?

Since the webcam program is interfering with NUT (rather than NUT preventing the webcam program from working), I would tend to consider it a bug in Cheese (or maybe the kernel USB drivers). Either way, you may get better results filing a bug at http://bugs.debian.org .

-- 
Charles Lepple
clepple at gmail