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

[Victor Porton]

26.11.2014, 06:30, "Charles Lepple" <clepple at gmail.com>:
> 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?

I re-plugged the camera into USB3.0 port to which was connected the UPS and UPS into a freed USB2.0 port.

This solved the problem, even despite of the webcam is accordingly dmesg "USB2.0 JPEG WebCam" (not USB3.0).

I will report the bug in Debian.

>>>>   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 .

--
Victor Porton - http://portonvictor.org