Nut upsuser - Nov 2014 - "Communications with UPS advice@localhost lost" when using an other USB device

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

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.317085] usb 4-1: new high-speed USB device number 2 using ehci-pci
> [ ???1.405223] tsc: Refined TSC clocksource calibration: 3395.557 MHz
> [ ???1.405228] Switching to clocksource tsc
> [ ???1.449642] usb 4-1: New USB device found, idVendor=8087, idProduct=0024
> [ ???1.449648] usb 4-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
> [ ???1.450058] hub 4-1:1.0: USB hub found
> [ ???1.450104] hub 4-1:1.0: 8 ports detected
> [ ???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.619262] usb 3-1.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
> [ ???1.619265] usb 3-1.3: Product: USB to Serial
> [ ???1.619268] usb 3-1.3: Manufacturer: INNO TECH
> [ ???1.623072] hidraw: raw HID events driver (C) Jiri Kosina
> [ ???1.625251] usbcore: registered new interface driver usbhid
> [ ???1.625253] usbhid: USB HID core driver
> [ ???1.626014] hid-generic 0003:0665:5161.0001: hiddev0,hidraw0: USB HID
v1.00 Device [INNO TECH USB to Serial] on usb-0000:00:1a.0-1.3/input0
> [ ???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
> [ ???1.786442] usb 3-1.4: New USB device strings: Mfr=32, Product=38,
SerialNumber=0
> [ ???1.786444] usb 3-1.4: Product: USB2.0 JPEG WebCam
> [ ???1.786445] usb 3-1.4: Manufacturer: TASCORP
> [ ???1.857918] usb 3-1.5: new low-speed USB device number 5 using ehci-pci
> [ ???1.953554] usb 3-1.5: New USB device found, idVendor=192f,
idProduct=0416
> [ ???1.953555] usb 3-1.5: New USB device strings: Mfr=0, Product=2,
SerialNumber=0
> [ ???1.953557] usb 3-1.5: Product: USB Optical Mouse
> [ ???1.955908] input: USB Optical Mouse as
/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.5/3-1.5:1.0/input/input0
> [ ???1.956020] hid-generic 0003:192F:0416.0002: input,hidraw1: USB HID
v1.11 Mouse [USB Optical Mouse] on usb-0000:00:1a.0-1.5/input0
> [ ???2.026157] usb 3-1.6: new low-speed USB device number 6 using ehci-pci
> [ ???2.124421] usb 3-1.6: New USB device found, idVendor=1c4f,
idProduct=0016
> [ ???2.124423] usb 3-1.6: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
> [ ???2.124424] usb 3-1.6: Product: USB Keyboard
> [ ???2.124425] usb 3-1.6: Manufacturer: SIGMACHIP
> [ ???2.127151] input: SIGMACHIP USB Keyboard as
/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.6/3-1.6:1.0/input/input1
> [ ???2.127217] hid-generic 0003:1C4F:0016.0003: input,hidraw2: USB HID
v1.10 Keyboard [SIGMACHIP USB Keyboard] on usb-0000:00:1a.0-1.6/input0
>
> 26.11.2014, 02:45, "Victor Porton" <porton at narod.ru>:
>> ?I use Debian jessie with nut-server 2.7.2-1+b3.
>>
>> ?Yesterday I've configured it for my new Advice PRS850 (a UPS with
USB interface).
>>
>> ?I also have an USB webcam (and also USB mouse and keyboard, but that
doesn't matter).
>>
>> ?When I start the program Cheese (a program which uses the webcam), I
receive the following broadcast message:
>>
>> ?"Communications with UPS advice at localhost lost"
>>
>> ?When I exit Cheese, I receive the following broadcast message:
>>
>> ?"Communications with UPS advice at localhost established"
>>
>> ?Please help to eliminate this buggy behavior.
>>
>> ?Shall we consider this very message as a bug report, or should I
report a bug otherwise somewhere?
>>
>> ?My /etc/nut/ups.conf :
>>
>> ?maxretry = 3
>>
>> ?[advice]
>> ?????driver = blazer_usb
>> ?????port = /dev/ttyS0
>> ?????vendorid = 0665
>> ?????productid = 5161
>>
>> ?--
>> ?Victor Porton - http://portonvictor.org
>>
>> ?_______________________________________________
>> ?Nut-upsuser mailing list
>> ?Nut-upsuser at lists.alioth.debian.org
>> ?http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>
> --
> Victor Porton - http://portonvictor.org
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
--
Victor Porton - http://portonvictor.org

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

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