* I need advice with UPS connection. @ 2020-11-10 3:00 David Niklas 2020-11-10 21:55 ` Alan Stern 2021-11-14 19:48 ` I need advice with UPS connection. (ping) David Niklas 0 siblings, 2 replies; 18+ messages in thread From: David Niklas @ 2020-11-10 3:00 UTC (permalink / raw) To: linux-usb; +Cc: linux-kernel-owner Hello, I'm running Linux Kernel 5.8.X on a Devuan (Debian) system. I connected my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and got: [739229.454592][T25544] usb 9-4: new low-speed USB device number 2 using ohci-pci [739229.635343][T25544] usb 9-4: config index 0 descriptor too short (expected 9, got 0) [739229.635348][T25544] usb 9-4: can't read configurations, error -22 [739229.791290][T25544] usb 9-4: new low-speed USB device number 3 using ohci-pci [739229.982414][T25544] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [739229.982421][T25544] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [739229.982426][T25544] usb 9-4: Product: HID UPS Battery [739229.982430][T25544] usb 9-4: Manufacturer: POWERCOM Co.,LTD [739229.982433][T25544] usb 9-4: SerialNumber: 004-0D9F-000 [739230.027616][T25544] hid-generic 0003:0D9F:0004.0004: hiddev1,hidraw2: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:00:16.0-4/input0 [739233.484723][T25544] usb 9-4: USB disconnect, device number 3 [739236.257951][T25544] usb 9-4: new low-speed USB device number 4 using ohci-pci [739236.475434][T25544] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [739236.475442][T25544] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [739236.520783][T25544] hid-generic 0003:0D9F:0004.0005: hiddev1,hidraw2: USB HID v1.00 Device [HID 0d9f:0004] on usb-0000:00:16.0-4/input0 [739239.933809][T25544] usb 9-4: USB disconnect, device number 4 [739242.701322][T25544] usb 9-4: new low-speed USB device number 5 using ohci-pci [739242.880035][T25544] usb 9-4: device descriptor read/all, error -62 [739243.034561][T25544] usb 9-4: new low-speed USB device number 6 using ohci-pci [739243.252040][T25544] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [739243.252042][T25544] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [739243.296444][T25544] hid-generic 0003:0D9F:0004.0006: hiddev1,hidraw2: USB HID v1.00 Device [HID 0d9f:0004] on usb-0000:00:16.0-4/input0 [739246.720152][T25544] usb 9-4: USB disconnect, device number 6 [739249.491330][T13473] usb 9-4: new low-speed USB device number 7 using ohci-pci [739249.718707][T13473] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [739249.718709][T13473] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [739249.718710][T13473] usb 9-4: Product: HID UPS Battery [739249.718711][T13473] usb 9-4: Manufacturer: POWERCOM Co.,LTD [739249.718712][T13473] usb 9-4: SerialNumber: 004-0D9F-000 [739249.751173][T13473] hid-generic 0003:0D9F:0004.0007: unknown main item tag 0x0 <snip class="spam-repeated-previous-message"> [739250.162392][T13473] hid-generic 0003:0D9F:0004.0007: unknown main item tag 0x0 [739250.162813][T13473] hid-generic 0003:0D9F:0004.0007: hidraw2: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:00:16.0-4/input0 [739253.165518][T13473] usb 9-4: USB disconnect, device number 7 ... I'd appreciate any advice trying to get my UPS to stay connected and not spam the kernel log. The UPS is about 1 year old. It's working fine. I just want to use nut or apcupsd with it. Thanks, David ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. 2020-11-10 3:00 I need advice with UPS connection David Niklas @ 2020-11-10 21:55 ` Alan Stern 2020-11-11 1:17 ` Hgntkwis 2021-11-14 19:48 ` I need advice with UPS connection. (ping) David Niklas 1 sibling, 1 reply; 18+ messages in thread From: Alan Stern @ 2020-11-10 21:55 UTC (permalink / raw) To: David Niklas, Jiri Kosina, Benjamin Tissoires; +Cc: linux-usb, linux-input +Jiri, Ben, and linux-input On Mon, Nov 09, 2020 at 10:00:00PM -0500, David Niklas wrote: > Hello, > I'm running Linux Kernel 5.8.X on a Devuan (Debian) system. I connected > my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and got: > > [739229.454592][T25544] usb 9-4: new low-speed USB device number 2 using ohci-pci > [739229.635343][T25544] usb 9-4: config index 0 descriptor too short (expected 9, got 0) > [739229.635348][T25544] usb 9-4: can't read configurations, error -22 > [739229.791290][T25544] usb 9-4: new low-speed USB device number 3 using ohci-pci > [739229.982414][T25544] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [739229.982421][T25544] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [739229.982426][T25544] usb 9-4: Product: HID UPS Battery > [739229.982430][T25544] usb 9-4: Manufacturer: POWERCOM Co.,LTD > [739229.982433][T25544] usb 9-4: SerialNumber: 004-0D9F-000 > [739230.027616][T25544] hid-generic 0003:0D9F:0004.0004: hiddev1,hidraw2: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:00:16.0-4/input0 > [739233.484723][T25544] usb 9-4: USB disconnect, device number 3 > [739236.257951][T25544] usb 9-4: new low-speed USB device number 4 using ohci-pci > [739236.475434][T25544] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [739236.475442][T25544] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [739236.520783][T25544] hid-generic 0003:0D9F:0004.0005: hiddev1,hidraw2: USB HID v1.00 Device [HID 0d9f:0004] on usb-0000:00:16.0-4/input0 > [739239.933809][T25544] usb 9-4: USB disconnect, device number 4 > [739242.701322][T25544] usb 9-4: new low-speed USB device number 5 using ohci-pci > [739242.880035][T25544] usb 9-4: device descriptor read/all, error -62 > [739243.034561][T25544] usb 9-4: new low-speed USB device number 6 using ohci-pci > [739243.252040][T25544] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [739243.252042][T25544] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [739243.296444][T25544] hid-generic 0003:0D9F:0004.0006: hiddev1,hidraw2: USB HID v1.00 Device [HID 0d9f:0004] on usb-0000:00:16.0-4/input0 > [739246.720152][T25544] usb 9-4: USB disconnect, device number 6 > [739249.491330][T13473] usb 9-4: new low-speed USB device number 7 using ohci-pci > [739249.718707][T13473] usb 9-4: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [739249.718709][T13473] usb 9-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [739249.718710][T13473] usb 9-4: Product: HID UPS Battery > [739249.718711][T13473] usb 9-4: Manufacturer: POWERCOM Co.,LTD > [739249.718712][T13473] usb 9-4: SerialNumber: 004-0D9F-000 > [739249.751173][T13473] hid-generic 0003:0D9F:0004.0007: unknown main item tag 0x0 > <snip class="spam-repeated-previous-message"> > [739250.162392][T13473] hid-generic 0003:0D9F:0004.0007: unknown main item tag 0x0 > [739250.162813][T13473] hid-generic 0003:0D9F:0004.0007: hidraw2: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:00:16.0-4/input0 > [739253.165518][T13473] usb 9-4: USB disconnect, device number 7 > ... > > > I'd appreciate any advice trying to get my UPS to stay connected and not > spam the kernel log. The UPS is about 1 year old. It's working fine. I > just want to use nut or apcupsd with it. > > Thanks, > David ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. 2020-11-10 21:55 ` Alan Stern @ 2020-11-11 1:17 ` Hgntkwis 2020-11-11 15:42 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: Hgntkwis @ 2020-11-11 1:17 UTC (permalink / raw) To: stern; +Cc: linux-usb, linux-input On Tue, 10 Nov 2020 16:55:11 -0500 Alan Stern <stern@rowland.harvard.edu> wrote: > On Mon, Nov 09, 2020 at 10:00:00PM -0500, David Niklas wrote: > > Hello, > > I'm running Linux Kernel 5.8.X on a Devuan (Debian) system. I > > connected my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and > > got: > > > > [739229.454592][T25544] usb 9-4: new low-speed USB device number 2 > > using ohci-pci [739229.635343][T25544] usb 9-4: config index 0 > > descriptor too short (expected 9, got 0) [739229.635348][T25544] usb > > 9-4: can't read configurations, error -22 [739229.791290][T25544] usb > > 9-4: new low-speed USB device number 3 using ohci-pci > > [739229.982414][T25544] usb 9-4: New USB device found, idVendor=0d9f, > > idProduct=0004, bcdDevice= 0.02 [739229.982421][T25544] usb 9-4: New > > USB device strings: Mfr=3, Product=1, SerialNumber=2 > > [739229.982426][T25544] usb 9-4: Product: HID UPS Battery > > [739229.982430][T25544] usb 9-4: Manufacturer: POWERCOM Co.,LTD > > [739229.982433][T25544] usb 9-4: SerialNumber: 004-0D9F-000 > > [739230.027616][T25544] hid-generic 0003:0D9F:0004.0004: > > hiddev1,hidraw2: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS > > Battery] on usb-0000:00:16.0-4/input0 [739233.484723][T25544] usb > > 9-4: USB disconnect, device number 3 [739236.257951][T25544] usb 9-4: > > new low-speed USB device number 4 using ohci-pci > > [739236.475434][T25544] usb 9-4: New USB device found, idVendor=0d9f, > > idProduct=0004, bcdDevice= 0.02 [739236.475442][T25544] usb 9-4: New > > USB device strings: Mfr=3, Product=1, SerialNumber=2 > > [739236.520783][T25544] hid-generic 0003:0D9F:0004.0005: > > hiddev1,hidraw2: USB HID v1.00 Device [HID 0d9f:0004] on > > usb-0000:00:16.0-4/input0 [739239.933809][T25544] usb 9-4: USB > > disconnect, device number 4 [739242.701322][T25544] usb 9-4: new > > low-speed USB device number 5 using ohci-pci [739242.880035][T25544] > > usb 9-4: device descriptor read/all, error -62 > > [739243.034561][T25544] usb 9-4: new low-speed USB device number 6 > > using ohci-pci [739243.252040][T25544] usb 9-4: New USB device found, > > idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > > [739243.252042][T25544] usb 9-4: New USB device strings: Mfr=3, > > Product=1, SerialNumber=2 [739243.296444][T25544] hid-generic > > 0003:0D9F:0004.0006: hiddev1,hidraw2: USB HID v1.00 Device [HID > > 0d9f:0004] on usb-0000:00:16.0-4/input0 [739246.720152][T25544] usb > > 9-4: USB disconnect, device number 6 [739249.491330][T13473] usb 9-4: > > new low-speed USB device number 7 using ohci-pci > > [739249.718707][T13473] usb 9-4: New USB device found, idVendor=0d9f, > > idProduct=0004, bcdDevice= 0.02 [739249.718709][T13473] usb 9-4: New > > USB device strings: Mfr=3, Product=1, SerialNumber=2 > > [739249.718710][T13473] usb 9-4: Product: HID UPS Battery > > [739249.718711][T13473] usb 9-4: Manufacturer: POWERCOM Co.,LTD > > [739249.718712][T13473] usb 9-4: SerialNumber: 004-0D9F-000 > > [739249.751173][T13473] hid-generic 0003:0D9F:0004.0007: unknown main > > item tag 0x0 <snip class="spam-repeated-previous-message"> > > [739250.162392][T13473] hid-generic 0003:0D9F:0004.0007: unknown main > > item tag 0x0 [739250.162813][T13473] hid-generic 0003:0D9F:0004.0007: > > hidraw2: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on > > usb-0000:00:16.0-4/input0 [739253.165518][T13473] usb 9-4: USB > > disconnect, device number 7 ... > > > > > > I'd appreciate any advice trying to get my UPS to stay connected and > > not spam the kernel log. The UPS is about 1 year old. It's working > > fine. I just want to use nut or apcupsd with it. > > > > Thanks, > > David > > +Jiri, Ben, and linux-input > I googled Jiri and ben but I don't see anything promising. Can you give me more search terms or absolute URLs? Also, in pointing me to the linux-input subsystem, are you recommending me to write a driver or something else? Thanks, David ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. 2020-11-11 1:17 ` Hgntkwis @ 2020-11-11 15:42 ` Alan Stern 0 siblings, 0 replies; 18+ messages in thread From: Alan Stern @ 2020-11-11 15:42 UTC (permalink / raw) To: Hgntkwis; +Cc: linux-usb, linux-input On Tue, Nov 10, 2020 at 08:17:35PM -0500, Hgntkwis@vfemail.net wrote: > On Tue, 10 Nov 2020 16:55:11 -0500 > Alan Stern <stern@rowland.harvard.edu> wrote: > > > > > > I'd appreciate any advice trying to get my UPS to stay connected and > > > not spam the kernel log. The UPS is about 1 year old. It's working > > > fine. I just want to use nut or apcupsd with it. > > > > > > Thanks, > > > David > > > > +Jiri, Ben, and linux-input > > > > I googled Jiri and ben but I don't see anything promising. Can you give > me more search terms or absolute URLs? Jiri Kosina and Benjamin Tissoires are the maintainers of Linux's HID (Human Interface Device) subsystem, which interacts closely with the Input subsystem. Your UPS uses the HID communication protocol, so they are the people best suited to fix its problems. > Also, in pointing me to the linux-input subsystem, are you recommending > me to write a driver or something else? I am recommending that the people who work on the Input subsystem should take a look at your bug report. Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* I need advice with UPS connection. (ping) 2020-11-10 3:00 I need advice with UPS connection David Niklas 2020-11-10 21:55 ` Alan Stern @ 2021-11-14 19:48 ` David Niklas 2021-11-14 21:14 ` Alan Stern 1 sibling, 1 reply; 18+ messages in thread From: David Niklas @ 2021-11-14 19:48 UTC (permalink / raw) To: linux-usb; +Cc: linux-kernel-owner, linux-input Hello, Almost 1 year ago to the date I posted a question regarding connecting my UPS to my PC (look for the same subject -ping). The input subsystem maintainers, Jiri Kosina or Ben Tissoires were asked to get back to me. No one ever did though. Now my UPS is *not* working correctly, and I'd really really like to be able to speak to it with my PC so I can (hopefully) figure out what's wrong with it. I'm running Linux Kernel 5.15.X on a Devuan (Debian) system. I connected my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and got (almost the same as last time...): [ 4236.165138] usb 3-2: new low-speed USB device number 2 using xhci_hcd [ 4236.325178] usb 3-2: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [ 4236.325183] usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 4236.325185] usb 3-2: Product: HID UPS Battery [ 4236.325187] usb 3-2: Manufacturer: POWERCOM Co.,LTD [ 4236.325188] usb 3-2: SerialNumber: 004-0D9F-000 [ 4236.423210] hid-generic 0003:0D9F:0004.000B: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4239.842223] usb 3-2: USB disconnect, device number 2 [ 4242.485126] usb 3-2: new low-speed USB device number 3 using xhci_hcd [ 4242.645075] usb 3-2: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [ 4242.645080] usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 4242.645082] usb 3-2: Product: HID UPS Battery [ 4242.645084] usb 3-2: Manufacturer: POWERCOM Co.,LTD [ 4242.645085] usb 3-2: SerialNumber: 004-0D9F-000 [ 4242.727148] hid-generic 0003:0D9F:0004.000C: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4246.135926] usb 3-2: USB disconnect, device number 3 [ 4248.781839] usb 3-2: new low-speed USB device number 4 using xhci_hcd [ 4248.942099] usb 3-2: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [ 4248.942104] usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 4248.942106] usb 3-2: Product: HID UPS Battery [ 4248.942108] usb 3-2: Manufacturer: POWERCOM Co.,LTD [ 4248.942109] usb 3-2: SerialNumber: 004-0D9F-000 [ 4249.031166] hid-generic 0003:0D9F:0004.000D: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4252.511996] usb 3-2: USB disconnect, device number 4 ... I'd appreciate any advice trying to get my UPS to stay connected and not spam the kernel log. I'd like to have nut or apcupsd talk to it. Thanks, David ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-14 19:48 ` I need advice with UPS connection. (ping) David Niklas @ 2021-11-14 21:14 ` Alan Stern 2021-11-15 3:02 ` David Niklas 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2021-11-14 21:14 UTC (permalink / raw) To: David Niklas; +Cc: linux-usb, linux-input On Sun, Nov 14, 2021 at 02:48:42PM -0500, David Niklas wrote: > Hello, > > Almost 1 year ago to the date I posted a question regarding connecting my > UPS to my PC (look for the same subject -ping). The input subsystem > maintainers, Jiri Kosina or Ben Tissoires were asked to get back to me. > No one ever did though. > > Now my UPS is *not* working correctly, and I'd really really like to be > able to speak to it with my PC so I can (hopefully) figure out what's > wrong with it. > > I'm running Linux Kernel 5.15.X on a Devuan (Debian) system. I connected > my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and got (almost the > same as last time...): > [ 4236.165138] usb 3-2: new low-speed USB device number 2 using xhci_hcd > [ 4236.325178] usb 3-2: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [ 4236.325183] usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [ 4236.325185] usb 3-2: Product: HID UPS Battery > [ 4236.325187] usb 3-2: Manufacturer: POWERCOM Co.,LTD > [ 4236.325188] usb 3-2: SerialNumber: 004-0D9F-000 > [ 4236.423210] hid-generic 0003:0D9F:0004.000B: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 > [ 4239.842223] usb 3-2: USB disconnect, device number 2 > [ 4242.485126] usb 3-2: new low-speed USB device number 3 using xhci_hcd > [ 4242.645075] usb 3-2: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [ 4242.645080] usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [ 4242.645082] usb 3-2: Product: HID UPS Battery > [ 4242.645084] usb 3-2: Manufacturer: POWERCOM Co.,LTD > [ 4242.645085] usb 3-2: SerialNumber: 004-0D9F-000 > [ 4242.727148] hid-generic 0003:0D9F:0004.000C: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 > [ 4246.135926] usb 3-2: USB disconnect, device number 3 > [ 4248.781839] usb 3-2: new low-speed USB device number 4 using xhci_hcd > [ 4248.942099] usb 3-2: New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > [ 4248.942104] usb 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > [ 4248.942106] usb 3-2: Product: HID UPS Battery > [ 4248.942108] usb 3-2: Manufacturer: POWERCOM Co.,LTD > [ 4248.942109] usb 3-2: SerialNumber: 004-0D9F-000 > [ 4249.031166] hid-generic 0003:0D9F:0004.000D: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 > [ 4252.511996] usb 3-2: USB disconnect, device number 4 > ... > > I'd appreciate any advice trying to get my UPS to stay connected and not > spam the kernel log. I'd like to have nut or apcupsd talk to it. It would help to see the details of the communication between the computer and the UPS. You can collect a usbmon trace by running (as superuser): cat /sys/kernel/debug/usb/usbmon/3u >mon.txt before plugging in the UPS cable. (The 3 comes from the bus number of the USB port in the log above.) Kill the process after the cable has been plugged in long enough for a couple of these disconnect messages to appear, and post the output file to the mailing list. Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-14 21:14 ` Alan Stern @ 2021-11-15 3:02 ` David Niklas 2021-11-15 16:09 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: David Niklas @ 2021-11-15 3:02 UTC (permalink / raw) To: linux-usb; +Cc: stern, linux-input, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3570 bytes --] On Sun, 14 Nov 2021 16:14:35 -0500 stern@rowland.harvard.edu wrote: > On Sun, Nov 14, 2021 at 02:48:42PM -0500, David Niklas wrote: > > Hello, > > > > Almost 1 year ago to the date I posted a question regarding > > connecting my UPS to my PC (look for the same subject -ping). The > > input subsystem maintainers, Jiri Kosina or Ben Tissoires were asked > > to get back to me. No one ever did though. > > > > Now my UPS is *not* working correctly, and I'd really really like to > > be able to speak to it with my PC so I can (hopefully) figure out > > what's wrong with it. > > > > I'm running Linux Kernel 5.15.X on a Devuan (Debian) system. I > > connected my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and > > got (almost the same as last time...): > > [ 4236.165138] usb 3-2: new low-speed USB device number 2 using > > xhci_hcd [ 4236.325178] usb 3-2: New USB device found, idVendor=0d9f, > > idProduct=0004, bcdDevice= 0.02 [ 4236.325183] usb 3-2: New USB > > device strings: Mfr=3, Product=1, SerialNumber=2 [ 4236.325185] usb > > 3-2: Product: HID UPS Battery [ 4236.325187] usb 3-2: Manufacturer: > > POWERCOM Co.,LTD [ 4236.325188] usb 3-2: SerialNumber: 004-0D9F-000 > > [ 4236.423210] hid-generic 0003:0D9F:0004.000B: hiddev3,hidraw8: USB > > HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on > > usb-0000:11:00.3-2/input0 [ 4239.842223] usb 3-2: USB disconnect, > > device number 2 [ 4242.485126] usb 3-2: new low-speed USB device > > number 3 using xhci_hcd [ 4242.645075] usb 3-2: New USB device found, > > idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [ 4242.645080] usb > > 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > > [ 4242.645082] usb 3-2: Product: HID UPS Battery [ 4242.645084] usb > > 3-2: Manufacturer: POWERCOM Co.,LTD [ 4242.645085] usb 3-2: > > SerialNumber: 004-0D9F-000 [ 4242.727148] hid-generic > > 0003:0D9F:0004.000C: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM > > Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4246.135926] > > usb 3-2: USB disconnect, device number 3 [ 4248.781839] usb 3-2: new > > low-speed USB device number 4 using xhci_hcd [ 4248.942099] usb 3-2: > > New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > > [ 4248.942104] usb 3-2: New USB device strings: Mfr=3, Product=1, > > SerialNumber=2 [ 4248.942106] usb 3-2: Product: HID UPS Battery > > [ 4248.942108] usb 3-2: Manufacturer: POWERCOM Co.,LTD [ 4248.942109] > > usb 3-2: SerialNumber: 004-0D9F-000 [ 4249.031166] hid-generic > > 0003:0D9F:0004.000D: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM > > Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4252.511996] > > usb 3-2: USB disconnect, device number 4 ... > > > > I'd appreciate any advice trying to get my UPS to stay connected and > > not spam the kernel log. I'd like to have nut or apcupsd talk to it. > > It would help to see the details of the communication between the > computer and the UPS. You can collect a usbmon trace by running (as > superuser): > > cat /sys/kernel/debug/usb/usbmon/3u >mon.txt > > before plugging in the UPS cable. (The 3 comes from the bus number of > the USB port in the log above.) Kill the process after the cable has > been plugged in long enough for a couple of these disconnect messages > to appear, and post the output file to the mailing list. > > Alan Stern > Attached is the info. In case someone doesn't realize, I'm subscribed to the linux-kernel ML, but not input or usb. Please CC me if you don't want to spam the LKML. Thanks for the timely response, David [-- Attachment #2: mon.txt.bz2 --] [-- Type: application/x-bzip, Size: 1990 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-15 3:02 ` David Niklas @ 2021-11-15 16:09 ` Alan Stern 2021-11-15 22:08 ` David Niklas 2021-11-17 5:23 ` David Niklas 0 siblings, 2 replies; 18+ messages in thread From: Alan Stern @ 2021-11-15 16:09 UTC (permalink / raw) To: David Niklas; +Cc: linux-usb, linux-input, linux-kernel On Sun, Nov 14, 2021 at 10:02:22PM -0500, David Niklas wrote: > On Sun, 14 Nov 2021 16:14:35 -0500 > stern@rowland.harvard.edu wrote: > > On Sun, Nov 14, 2021 at 02:48:42PM -0500, David Niklas wrote: > > > Hello, > > > > > > Almost 1 year ago to the date I posted a question regarding > > > connecting my UPS to my PC (look for the same subject -ping). The > > > input subsystem maintainers, Jiri Kosina or Ben Tissoires were asked > > > to get back to me. No one ever did though. > > > > > > Now my UPS is *not* working correctly, and I'd really really like to > > > be able to speak to it with my PC so I can (hopefully) figure out > > > what's wrong with it. > > > > > > I'm running Linux Kernel 5.15.X on a Devuan (Debian) system. I > > > connected my UPS (OPTI-UPS Thunder Shield TS2250B) via USB cable and > > > got (almost the same as last time...): > > > [ 4236.165138] usb 3-2: new low-speed USB device number 2 using > > > xhci_hcd [ 4236.325178] usb 3-2: New USB device found, idVendor=0d9f, > > > idProduct=0004, bcdDevice= 0.02 [ 4236.325183] usb 3-2: New USB > > > device strings: Mfr=3, Product=1, SerialNumber=2 [ 4236.325185] usb > > > 3-2: Product: HID UPS Battery [ 4236.325187] usb 3-2: Manufacturer: > > > POWERCOM Co.,LTD [ 4236.325188] usb 3-2: SerialNumber: 004-0D9F-000 > > > [ 4236.423210] hid-generic 0003:0D9F:0004.000B: hiddev3,hidraw8: USB > > > HID v1.00 Device [POWERCOM Co.,LTD HID UPS Battery] on > > > usb-0000:11:00.3-2/input0 [ 4239.842223] usb 3-2: USB disconnect, > > > device number 2 [ 4242.485126] usb 3-2: new low-speed USB device > > > number 3 using xhci_hcd [ 4242.645075] usb 3-2: New USB device found, > > > idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 [ 4242.645080] usb > > > 3-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2 > > > [ 4242.645082] usb 3-2: Product: HID UPS Battery [ 4242.645084] usb > > > 3-2: Manufacturer: POWERCOM Co.,LTD [ 4242.645085] usb 3-2: > > > SerialNumber: 004-0D9F-000 [ 4242.727148] hid-generic > > > 0003:0D9F:0004.000C: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM > > > Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4246.135926] > > > usb 3-2: USB disconnect, device number 3 [ 4248.781839] usb 3-2: new > > > low-speed USB device number 4 using xhci_hcd [ 4248.942099] usb 3-2: > > > New USB device found, idVendor=0d9f, idProduct=0004, bcdDevice= 0.02 > > > [ 4248.942104] usb 3-2: New USB device strings: Mfr=3, Product=1, > > > SerialNumber=2 [ 4248.942106] usb 3-2: Product: HID UPS Battery > > > [ 4248.942108] usb 3-2: Manufacturer: POWERCOM Co.,LTD [ 4248.942109] > > > usb 3-2: SerialNumber: 004-0D9F-000 [ 4249.031166] hid-generic > > > 0003:0D9F:0004.000D: hiddev3,hidraw8: USB HID v1.00 Device [POWERCOM > > > Co.,LTD HID UPS Battery] on usb-0000:11:00.3-2/input0 [ 4252.511996] > > > usb 3-2: USB disconnect, device number 4 ... > > > > > > I'd appreciate any advice trying to get my UPS to stay connected and > > > not spam the kernel log. I'd like to have nut or apcupsd talk to it. > > > > It would help to see the details of the communication between the > > computer and the UPS. You can collect a usbmon trace by running (as > > superuser): > > > > cat /sys/kernel/debug/usb/usbmon/3u >mon.txt > > > > before plugging in the UPS cable. (The 3 comes from the bus number of > > the USB port in the log above.) Kill the process after the cable has > > been plugged in long enough for a couple of these disconnect messages > > to appear, and post the output file to the mailing list. > > > > Alan Stern > > > > Attached is the info. > > In case someone doesn't realize, I'm subscribed to the linux-kernel ML, > but not input or usb. Please CC me if you don't want to spam the LKML. Has this device ever worked with any version of Linux? The usbmon trace is not terribly revealing. Here are the important parts from one connect/disconnect cycle. (FYI, the second column of each line is a timestamp in microseconds.) ffff93eaa3edad80 2135760066 S Ci:3:001:0 s a3 00 0000 0003 0004 4 < ffff93eaa3edad80 2135760074 C Ci:3:001:0 0 4 = 01030000 The kernel learns that there is a connection on port 3 of bus 3. ffff93eaa3edad80 2135760113 S Co:3:001:0 s 23 03 0004 0003 0000 0 ffff93eaa3edad80 2135760117 C Co:3:001:0 0 0 The kernel tells the USB host controller to reset the port. ffff93eaa3edad80 2135826729 S Ci:3:001:0 s a3 00 0000 0003 0004 4 < ffff93eaa3edad80 2135826739 C Ci:3:001:0 0 4 = 03031000 The kernel sees that the reset is complete and the port is enabled. ffff93eaa3edad80 2135826742 S Co:3:001:0 s 23 01 0014 0003 0000 0 ffff93eaa3edad80 2135826744 C Co:3:001:0 0 0 The kernel clears the "reset complete" status flag. ffff93eaa3edad80 2135883456 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff93eaa3edad80 2135885736 C Ci:3:000:0 0 18 = 12011001 00000008 9f0d0400 02000301 0201 The computer reads the device descriptor for the first time. ffff93eaa3edad80 2135885741 S Co:3:001:0 s 23 03 0004 0003 0000 0 ffff93eaa3edad80 2135885746 C Co:3:001:0 0 0 ffff93eaa3edad80 2135950054 S Ci:3:001:0 s a3 00 0000 0003 0004 4 < ffff93eaa3edad80 2135950060 C Ci:3:001:0 0 4 = 03031000 ffff93eaa3edad80 2135950063 S Co:3:001:0 s 23 01 0014 0003 0000 0 ffff93eaa3edad80 2135950066 C Co:3:001:0 0 0 Another reset, reset complete, clear "reset complete" flag series. This is the normal sequence used every time a device gets connected. ffff93eaa3edad80 2136023391 S Ci:3:009:0 s 80 06 0100 0000 0012 18 < ffff93eaa3edad80 2136025736 C Ci:3:009:0 0 18 = 12011001 00000008 9f0d0400 02000301 0201 The kernel reads the device descriptor a second time. ffff93eaa3edad80 2136025745 S Ci:3:009:0 s 80 06 0200 0000 0009 9 < ffff93eaa3edad80 2136028735 C Ci:3:009:0 0 9 = 09022200 010100a0 32 The kernel reads the device's configuration descriptor. ffff93eaa3edad80 2136028738 S Ci:3:009:0 s 80 06 0200 0000 0022 34 < ffff93eaa3edad80 2136031810 C Ci:3:009:0 0 34 = 09022200 010100a0 32090400 00010300 00000921 00010001 22e40307 05810308 The kernel reads the device's configuration, interface, and endpoint descriptors. ffff93eaa3edad80 2136031818 S Ci:3:009:0 s 80 06 0300 0000 00ff 255 < ffff93eaa3edad80 2136034734 C Ci:3:009:0 0 6 = 06030904 0408 ffff93eaa3edad80 2136034738 S Ci:3:009:0 s 80 06 0301 0409 00ff 255 < ffff93eaa3edad80 2136037799 C Ci:3:009:0 0 32 = 20034800 49004400 20005500 50005300 20004200 61007400 74006500 72007900 ffff93eaa3edad80 2136037803 S Ci:3:009:0 s 80 06 0303 0409 00ff 255 < ffff93eaa3edad80 2136040810 C Ci:3:009:0 0 34 = 22035000 4f005700 45005200 43004f00 4d002000 43006f00 2e002c00 4c005400 ffff93eaa3edad80 2136040816 S Ci:3:009:0 s 80 06 0302 0409 00ff 255 < ffff93eaa3edad80 2136043734 C Ci:3:009:0 0 26 = 1a033000 30003400 2d003000 44003900 46002d00 30003000 3000 The kernel reads several string descriptors. If you're good at translating UTF-16LE codes from hex to normal characters, you can find the truncated strings "HID UPS Battery", "POWERCOM Co.,LT", and "004-0D9F-000" that make up the vendor, product (slightly truncated), and serial number string descriptors. Reading these descriptors is part of the normal enumeration process that happens whenever a USB device is plugged in. ffff93eaa3edad80 2136080671 S Co:3:009:0 s 00 09 0001 0000 0000 0 ffff93eaa3edad80 2136081734 C Co:3:009:0 0 0 The kernel tells the device to install its first (and in this case, only) configuration. Also very normal, and necessary for proper operation. ffff93eaa3edad80 2136081778 S Ci:3:009:0 s 80 06 0302 0409 00ff 255 < ffff93eaa3edad80 2136084734 C Ci:3:009:0 0 26 = 1a033000 30003400 2d003000 44003900 46002d00 30003000 3000 The kernel reads the serial number string descriptor descriptor again. ffff93eaa3edad80 2136084747 S Co:3:009:0 s 21 0a 0000 0000 0000 0 ffff93eaa3edad80 2136086733 C Co:3:009:0 0 0 The kernel sends a Set-Idle request to the device, telling it not to send any data reports when nothing has changed. This is done automatically by the usbhid driver for every USB HID device, including keyboards and mice as well as your UPS. ffff93eaa3edad80 2136086737 S Ci:3:009:0 s 81 06 2200 0000 03e4 996 < ffff93eaa3edad80 2136122734 C Ci:3:009:0 0 996 = 05840904 a1010924 a1028501 09fe7901 75089501 150026ff 00b12285 0209ff79 The kernel reads the device's HID descriptor. (The usbmon trace shows only the first 32 bytes of the 996-byte descriptor.) Again, this is normal and necessary for using any HID device. ffff93e482efb440 2139520170 C Ii:3:001:1 0:2048 1 = 08 ffff93e482efb440 2139520180 S Ii:3:001:1 -115:2048 4 < At this point the USB controller tells the kernel that there has been a status change on port 3 of bus 3. ffff93eaa2ff8240 2139520188 S Ci:3:001:0 s a3 00 0000 0003 0004 4 < ffff93eaa2ff8240 2139520197 C Ci:3:001:0 0 4 = 00010100 The kernel reads the port's status and sees that there is a "connection status change" bit set and the port is no longer connected. In other words, the UPS device has disconnected itself electronically from the USB bus. ffff93eaa2ff8240 2139520200 S Co:3:001:0 s 23 01 0010 0003 0000 0 ffff93eaa2ff8240 2139520203 C Co:3:001:0 0 0 The kernel clears the "connection status change" flag. Following this the cycle repeats. Out of all this information, the only conclusion I can draw is that the UPS is not behaving like a normal device. One possibility is that it doesn't like the Set-Idle request (although if that is the case, why did it remain connected long enough to send the HID descriptor?). You can test the theory by patching the kernel, if you want. The code to change is in the source file drivers/hid/usbhid/hid-core.c, and the function in question is hid_set_idle() located around line 659 in the file. Just change the statement: return usb_control_msg(dev, usb_sndctrlpipe(dev, 0), HID_REQ_SET_IDLE, USB_TYPE_CLASS | USB_RECIP_INTERFACE, (idle << 8) | report, ifnum, NULL, 0, USB_CTRL_SET_TIMEOUT); to: return 0; to prevent the Set-Idle request from being sent. If the device still insists on disconnecting then we'll know that this wasn't the reason. Also, if you have another system (say, one running Windows) which the UPS does work properly with, you could try collecting the equivalent of a usbmon trace from that system for purposes of comparison. (On Windows, I believe you can use Wireshark to trace USB communications.) Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-15 16:09 ` Alan Stern @ 2021-11-15 22:08 ` David Niklas 2021-11-17 5:23 ` David Niklas 1 sibling, 0 replies; 18+ messages in thread From: David Niklas @ 2021-11-15 22:08 UTC (permalink / raw) To: linux-kernel; +Cc: stern, linux-usb, linux-input On Mon, 15 Nov 2021 11:09:18 -0500 stern@rowland.harvard.edu wrote: > On Sun, Nov 14, 2021 at 10:02:22PM -0500, David Niklas wrote: > > <snip> > Has this device ever worked with any version of Linux? I am unaware of this device working on any version of Linux. I assumed when I bought it that it would a least be able to connect to the USB port correctly. I might then have to make a contribution to add support for it to nut or apcupsd. <snip> > The kernel sends a Set-Idle request to the device, telling it not to > send any data reports when nothing has changed. This is done > automatically by the usbhid driver for every USB HID device, including > keyboards and mice as well as your UPS. > > ffff93eaa3edad80 2136086737 S Ci:3:009:0 s 81 06 2200 0000 03e4 996 < > ffff93eaa3edad80 2136122734 C Ci:3:009:0 0 996 = 05840904 a1010924 > a1028501 09fe7901 75089501 150026ff 00b12285 0209ff79 > > The kernel reads the device's HID descriptor. (The usbmon trace shows > only the first 32 bytes of the 996-byte descriptor.) Again, this is > normal and necessary for using any HID device. > > ffff93e482efb440 2139520170 C Ii:3:001:1 0:2048 1 = 08 > ffff93e482efb440 2139520180 S Ii:3:001:1 -115:2048 4 < > > At this point the USB controller tells the kernel that there has been a > status change on port 3 of bus 3. > > ffff93eaa2ff8240 2139520188 S Ci:3:001:0 s a3 00 0000 0003 0004 4 < > ffff93eaa2ff8240 2139520197 C Ci:3:001:0 0 4 = 00010100 > > The kernel reads the port's status and sees that there is a "connection > status change" bit set and the port is no longer connected. In other > words, the UPS device has disconnected itself electronically from the > USB bus. > > ffff93eaa2ff8240 2139520200 S Co:3:001:0 s 23 01 0010 0003 0000 0 > ffff93eaa2ff8240 2139520203 C Co:3:001:0 0 0 > > The kernel clears the "connection status change" flag. Following this > the cycle repeats. > > > Out of all this information, the only conclusion I can draw is that the > UPS is not behaving like a normal device. One possibility is that it > doesn't like the Set-Idle request (although if that is the case, why > did it remain connected long enough to send the HID descriptor?). Thanks for the detailed breakdown! > You can test the theory by patching the kernel, if you want. The code > to change is in the source file drivers/hid/usbhid/hid-core.c, and the > function in question is hid_set_idle() located around line 659 in the > file. Just change the statement: > > return usb_control_msg(dev, usb_sndctrlpipe(dev, 0), > HID_REQ_SET_IDLE, USB_TYPE_CLASS | USB_RECIP_INTERFACE, > (idle << 8) | report, ifnum, NULL, 0, USB_CTRL_SET_TIMEOUT); > > to: > > return 0; > > to prevent the Set-Idle request from being sent. If the device still > insists on disconnecting then we'll know that this wasn't the reason. Will do tomorrow. (I'm busy ATM) > Also, if you have another system (say, one running Windows) which the > UPS does work properly with, you could try collecting the equivalent of > a usbmon trace from that system for purposes of comparison. (On > Windows, I believe you can use Wireshark to trace USB communications.) > > Alan Stern > I'll have to look into that. Thanks again! David ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-15 16:09 ` Alan Stern 2021-11-15 22:08 ` David Niklas @ 2021-11-17 5:23 ` David Niklas 2021-11-17 17:08 ` Alan Stern 1 sibling, 1 reply; 18+ messages in thread From: David Niklas @ 2021-11-17 5:23 UTC (permalink / raw) To: linux-kernel; +Cc: stern, linux-usb, linux-input [-- Attachment #1: Type: text/plain, Size: 3009 bytes --] On Mon, 15 Nov 2021 11:09:18 -0500 stern@rowland.harvard.edu wrote: <snip> > You can test the theory by patching the kernel, if you want. The code > to change is in the source file drivers/hid/usbhid/hid-core.c, and the > function in question is hid_set_idle() located around line 659 in the > file. Just change the statement: > > return usb_control_msg(dev, usb_sndctrlpipe(dev, 0), > HID_REQ_SET_IDLE, USB_TYPE_CLASS | USB_RECIP_INTERFACE, > (idle << 8) | report, ifnum, NULL, 0, USB_CTRL_SET_TIMEOUT); > > to: > > return 0; > > to prevent the Set-Idle request from being sent. If the device still > insists on disconnecting then we'll know that this wasn't the reason. > Ok, so I changed out the line above with "__panic(2);" and now my PC just reboots.... Teasing :D That didn't seem to change anything. I'll attach another dump just in case it reveals more. > Also, if you have another system (say, one running Windows) which the > UPS does work properly with, you could try collecting the equivalent of > a usbmon trace from that system for purposes of comparison. (On > Windows, I believe you can use Wireshark to trace USB communications.) > Limitations of SW: Wireshark works if you have windows in a virtual environment, but I don't actually own... I mean license, any windowz products. I'm a straight Luser. So borrowed a windowz machine and plugged in the UPS. I then used USBPcap to capture the data after installing the drivers. It has 4 things it can't detect: Bus states (Suspended, Power ON, Power OFF, Reset, High Speed Detection Handshake) Packet ID (PID) Split transactions (CSPLIT, SSPLIT) Duration of bus state and time used to transfer packet over the wire Transfer speed (Low Speed, Full Speed, High Speed) I'm 100% certain the last 2 we don't care about. IDK about the others. Notes: Here's the product page of my UPS. https://www.newegg.com/opti-ups-ts2250b/p/N82E16842107014 The main webpage for USBPcap is here: https://desowin.org/usbpcap/index.html I can also try and use SnoopyPro and busdog if the output is undesirable. USBPcap spits out a pcap file which can be analyzed by wireshark using dissectors -- somehow (I really should practice using wireshark.) Test and capture procedure: When I installed the drivers it asked me where to look for the UPS. I didn't tell it the USB port until after I started USBPcap and then plugged in the UPS. Then the GUI opened up and I could see a lot of cool controls like the battery power, loading, etc. The loading was 132W and the battery was at 100%. Then I ran a self test (There's a button in the GUI) and it worked fine. Then I unplugged the UPS and it crashed. Then I plugged it back in. All --100%-- of this is in the pcap file. Results of: After unplugging the UPS it's battery dropped to 22% and then it turned off. My UPS is 2y and 5m old. It has a 3Y parts warranty. I guess I'll see if they'll honor it. I'm still interested in talking to it via my Linux PC, of course. Thanks, David [-- Attachment #2: kernel-usb.txt.bz2 --] [-- Type: application/x-bzip, Size: 1647 bytes --] [-- Attachment #3: ups.pcap.xz --] [-- Type: application/x-xz, Size: 15860 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-17 5:23 ` David Niklas @ 2021-11-17 17:08 ` Alan Stern 2021-11-19 22:19 ` David Niklas 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2021-11-17 17:08 UTC (permalink / raw) To: David Niklas; +Cc: linux-kernel, linux-usb, linux-input On Wed, Nov 17, 2021 at 12:23:59AM -0500, David Niklas wrote: > On Mon, 15 Nov 2021 11:09:18 -0500 > stern@rowland.harvard.edu wrote: > <snip> > > You can test the theory by patching the kernel, if you want. The code > > to change is in the source file drivers/hid/usbhid/hid-core.c, and the > > function in question is hid_set_idle() located around line 659 in the > > file. Just change the statement: > > > > return usb_control_msg(dev, usb_sndctrlpipe(dev, 0), > > HID_REQ_SET_IDLE, USB_TYPE_CLASS | USB_RECIP_INTERFACE, > > (idle << 8) | report, ifnum, NULL, 0, USB_CTRL_SET_TIMEOUT); > > > > to: > > > > return 0; > > > > to prevent the Set-Idle request from being sent. If the device still > > insists on disconnecting then we'll know that this wasn't the reason. > > > > Ok, so I changed out the line above with "__panic(2);" and now my PC just > reboots.... Teasing :D > That didn't seem to change anything. I'll attach another dump just in > case it reveals more. It doesn't. :-( The Set-Idle request does not appear to be related to the problem. > > Also, if you have another system (say, one running Windows) which the > > UPS does work properly with, you could try collecting the equivalent of > > a usbmon trace from that system for purposes of comparison. (On > > Windows, I believe you can use Wireshark to trace USB communications.) > > > > Limitations of SW: > Wireshark works if you have windows in a virtual environment, but I don't > actually own... I mean license, any windowz products. I'm a straight > Luser. > So borrowed a windowz machine and plugged in the UPS. I then used USBPcap > to capture the data after installing the drivers. It has 4 things it can't > detect: > > Bus states (Suspended, Power ON, Power OFF, Reset, High Speed Detection > Handshake) > Packet ID (PID) > Split transactions (CSPLIT, SSPLIT) > Duration of bus state and time used to transfer packet over the wire > Transfer speed (Low Speed, Full Speed, High Speed) > > I'm 100% certain the last 2 we don't care about. IDK about the others. I don't think they matter. In principle the time delays might be important, but I rather doubt it. > Notes: > Here's the product page of my UPS. > https://www.newegg.com/opti-ups-ts2250b/p/N82E16842107014 > The main webpage for USBPcap is here: > https://desowin.org/usbpcap/index.html > I can also try and use SnoopyPro and busdog if the output is undesirable. > USBPcap spits out a pcap file which can be analyzed by wireshark > using dissectors -- somehow (I really should practice using wireshark.) Wireshark on my system has no trouble reading your pcap file. > Test and capture procedure: > When I installed the drivers it asked me where to look for the UPS. I > didn't tell it the USB port until after I started USBPcap and then > plugged in the UPS. Then the GUI opened up and I could see a lot of cool > controls like the battery power, loading, etc. The loading was 132W and > the battery was at 100%. Then I ran a self test (There's a button in the > GUI) and it worked fine. Then I unplugged the UPS and it crashed. Then I > plugged it back in. All --100%-- of this is in the pcap file. I'm just concentrating on the first part, up to the point where the unwanted disconnects occurred with Linux. So far as I can see, there are only two significant differences between the usbmon and wireshark traces: The Windows system doesn't transfer any of the string descriptors during initial enumeration, whereas the Linux system does. While this might be relevant, I don't think it is. When the Windows system requests the HID report descriptor from the device, it asks for 1060 bytes of data. The Linux system asks for only 996 bytes. (Note: The descriptor is exactly 996 bytes long, and that's how much data the device sends in either case.) It's entirely possible that this second discrepancy is somehow causing the problem. You can test this guess by applying the following patch: --- usb-devel.orig/drivers/hid/usbhid/hid-core.c +++ usb-devel/drivers/hid/usbhid/hid-core.c @@ -667,13 +667,16 @@ static int hid_get_class_descriptor(stru unsigned char type, void *buf, int size) { int result, retries = 4; + int size2 = size; + if (size == 996) + size2 = 1060; memset(buf, 0, size); do { result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), USB_REQ_GET_DESCRIPTOR, USB_RECIP_INTERFACE | USB_DIR_IN, - (type << 8), ifnum, buf, size, USB_CTRL_GET_TIMEOUT); + (type << 8), ifnum, buf, size2, USB_CTRL_GET_TIMEOUT); retries--; } while (result < size && retries); return result; This will cause the kernel to ask for 1060 bytes rather than 996. (It's also potentially dangerous, because it asks for 1060 bytes to be stored into a 996-byte buffer; if the device sends more data than expected then the excess will be written beyond the end of the buffer.) Please send a usbmon trace showing what happens with this patch applied. And you might as well put the Set-Idle request back in, because now we know Windows does send that request. > Results of: > After unplugging the UPS it's battery dropped to 22% and then it turned > off. My UPS is 2y and 5m old. It has a 3Y parts warranty. I guess I'll > see if they'll honor it. > > > > > I'm still interested in talking to it via my Linux PC, of course. Let's see if the patch will avert the disconnect. Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-17 17:08 ` Alan Stern @ 2021-11-19 22:19 ` David Niklas 2021-11-21 2:54 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: David Niklas @ 2021-11-19 22:19 UTC (permalink / raw) To: linux-kernel; +Cc: Alan Stern, linux-usb, linux-input [-- Attachment #1: Type: text/plain, Size: 5727 bytes --] On Wed, 17 Nov 2021 12:08:17 -0500 Alan Stern <stern@rowland.harvard.edu> wrote: > On Wed, Nov 17, 2021 at 12:23:59AM -0500, David Niklas wrote: > > On Mon, 15 Nov 2021 11:09:18 -0500 > > stern@rowland.harvard.edu wrote: > > <snip> > > > You can test the theory by patching the kernel, if you want. The > > > code to change is in the source file drivers/hid/usbhid/hid-core.c, > > > and the function in question is hid_set_idle() located around line > > > 659 in the file. Just change the statement: > > > > > > return usb_control_msg(dev, usb_sndctrlpipe(dev, 0), > > > HID_REQ_SET_IDLE, USB_TYPE_CLASS | > > > USB_RECIP_INTERFACE, (idle << 8) | report, ifnum, NULL, 0, > > > USB_CTRL_SET_TIMEOUT); > > > > > > to: > > > > > > return 0; > > > > > > to prevent the Set-Idle request from being sent. If the device > > > still insists on disconnecting then we'll know that this wasn't the > > > reason. > > > > Ok, so I changed out the line above with "__panic(2);" and now my PC > > just reboots.... Teasing :D > > That didn't seem to change anything. I'll attach another dump just in > > case it reveals more. > > It doesn't. :-( The Set-Idle request does not appear to be related to > the problem. > > > > Also, if you have another system (say, one running Windows) which > > > the UPS does work properly with, you could try collecting the > > > equivalent of a usbmon trace from that system for purposes of > > > comparison. (On Windows, I believe you can use Wireshark to trace > > > USB communications.) > > > > Limitations of SW: > > Wireshark works if you have windows in a virtual environment, but I > > don't actually own... I mean license, any windowz products. I'm a > > straight Luser. > > So borrowed a windowz machine and plugged in the UPS. I then used > > USBPcap to capture the data after installing the drivers. It has 4 > > things it can't detect: > > > > Bus states (Suspended, Power ON, Power OFF, Reset, High Speed > > Detection Handshake) > > Packet ID (PID) > > Split transactions (CSPLIT, SSPLIT) > > Duration of bus state and time used to transfer packet over the wire > > Transfer speed (Low Speed, Full Speed, High Speed) > > > > I'm 100% certain the last 2 we don't care about. IDK about the > > others. > > I don't think they matter. In principle the time delays might be > important, but I rather doubt it. > > > Notes: > > Here's the product page of my UPS. > > https://www.newegg.com/opti-ups-ts2250b/p/N82E16842107014 > > The main webpage for USBPcap is here: > > https://desowin.org/usbpcap/index.html > > I can also try and use SnoopyPro and busdog if the output is > > undesirable. USBPcap spits out a pcap file which can be analyzed by > > wireshark using dissectors -- somehow (I really should practice using > > wireshark.) > > Wireshark on my system has no trouble reading your pcap file. Misunderstanding then. I was thinking in terms of the USBPcap docs. I was saying a dissector would need to be written. I'm glad it worked for you. https://desowin.org/usbpcap/dissectors.html "Writing USB class dissector" > > Test and capture procedure: > > When I installed the drivers it asked me where to look for the UPS. I > > didn't tell it the USB port until after I started USBPcap and then > > plugged in the UPS. Then the GUI opened up and I could see a lot of > > cool controls like the battery power, loading, etc. The loading was > > 132W and the battery was at 100%. Then I ran a self test (There's a > > button in the GUI) and it worked fine. Then I unplugged the UPS and > > it crashed. Then I plugged it back in. All --100%-- of this is in the > > pcap file. > > I'm just concentrating on the first part, up to the point where the > unwanted disconnects occurred with Linux. So far as I can see, there > are only two significant differences between the usbmon and wireshark > traces: > > The Windows system doesn't transfer any of the string > descriptors during initial enumeration, whereas the Linux > system does. While this might be relevant, I don't think it is. > > When the Windows system requests the HID report descriptor from > the device, it asks for 1060 bytes of data. The Linux system > asks for only 996 bytes. (Note: The descriptor is exactly > 996 bytes long, and that's how much data the device sends in > either case.) > > It's entirely possible that this second discrepancy is somehow causing > the problem. You can test this guess by applying the following patch: > > --- usb-devel.orig/drivers/hid/usbhid/hid-core.c > +++ usb-devel/drivers/hid/usbhid/hid-core.c > @@ -667,13 +667,16 @@ static int hid_get_class_descriptor(stru > unsigned char type, void *buf, int size) > { > int result, retries = 4; > + int size2 = size; > > + if (size == 996) > + size2 = 1060; > memset(buf, 0, size); > > do { > result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0), > USB_REQ_GET_DESCRIPTOR, > USB_RECIP_INTERFACE | USB_DIR_IN, > - (type << 8), ifnum, buf, size, > USB_CTRL_GET_TIMEOUT); > + (type << 8), ifnum, buf, size2, > USB_CTRL_GET_TIMEOUT); retries--; > } while (result < size && retries); > return result; > > This will cause the kernel to ask for 1060 bytes rather than 996. > (It's also potentially dangerous, because it asks for 1060 bytes to be > stored into a 996-byte buffer; if the device sends more data than > expected then the excess will be written beyond the end of the buffer.) > > Please send a usbmon trace showing what happens with this patch > applied. And you might as well put the Set-Idle request back in, > because now we know Windows does send that request. > <snip> It still disconnects. I've attached the usbmon output. Thanks, David [-- Attachment #2: mon2.txt.bz2 --] [-- Type: application/x-bzip, Size: 1734 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-19 22:19 ` David Niklas @ 2021-11-21 2:54 ` Alan Stern 2021-11-22 16:25 ` David Niklas 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2021-11-21 2:54 UTC (permalink / raw) To: David Niklas; +Cc: linux-kernel, linux-usb, linux-input On Fri, Nov 19, 2021 at 05:19:15PM -0500, David Niklas wrote: > On Wed, 17 Nov 2021 12:08:17 -0500 > Alan Stern <stern@rowland.harvard.edu> wrote: > > On Wed, Nov 17, 2021 at 12:23:59AM -0500, David Niklas wrote: > > > I can also try and use SnoopyPro and busdog if the output is > > > undesirable. USBPcap spits out a pcap file which can be analyzed by > > > wireshark using dissectors -- somehow (I really should practice using > > > wireshark.) > > > > Wireshark on my system has no trouble reading your pcap file. > > Misunderstanding then. I was thinking in terms of the USBPcap docs. I was > saying a dissector would need to be written. I'm glad it worked for you. > https://desowin.org/usbpcap/dissectors.html > "Writing USB class dissector" Evidently wireshark already has built-in dissectors for standard USB communications. > > This will cause the kernel to ask for 1060 bytes rather than 996. > > (It's also potentially dangerous, because it asks for 1060 bytes to be > > stored into a 996-byte buffer; if the device sends more data than > > expected then the excess will be written beyond the end of the buffer.) > > > > Please send a usbmon trace showing what happens with this patch > > applied. And you might as well put the Set-Idle request back in, > > because now we know Windows does send that request. > > > <snip> > > It still disconnects. I've attached the usbmon output. The trace clearly shows the request for a 1060-byte HID report descriptor and the device sending back a 996-byte reply, just like in Windows. And yet the disconnect still occurs. The only remaining difference is the transfer of string descriptors. You can prevent Linux from asking for them by editing usb_string() in drivers/usb/core/message.c. Just make the function return -ENOMEM unconditionally. That will stop the requests from going out. Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-21 2:54 ` Alan Stern @ 2021-11-22 16:25 ` David Niklas 2021-11-22 20:13 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: David Niklas @ 2021-11-22 16:25 UTC (permalink / raw) To: Alan Stern; +Cc: linux-kernel, linux-usb, linux-input [-- Attachment #1: Type: text/plain, Size: 1632 bytes --] On Sat, 20 Nov 2021 21:54:20 -0500 Alan Stern <stern@rowland.harvard.edu> wrote: > On Fri, Nov 19, 2021 at 05:19:15PM -0500, David Niklas wrote: > > On Wed, 17 Nov 2021 12:08:17 -0500 > > Alan Stern <stern@rowland.harvard.edu> wrote: <snip> > > > This will cause the kernel to ask for 1060 bytes rather than 996. > > > (It's also potentially dangerous, because it asks for 1060 bytes to > > > be stored into a 996-byte buffer; if the device sends more data than > > > expected then the excess will be written beyond the end of the > > > buffer.) > > > > > > Please send a usbmon trace showing what happens with this patch > > > applied. And you might as well put the Set-Idle request back in, > > > because now we know Windows does send that request. > > > > > <snip> > > > > It still disconnects. I've attached the usbmon output. > > The trace clearly shows the request for a 1060-byte HID report > descriptor and the device sending back a 996-byte reply, just like in > Windows. And yet the disconnect still occurs. > > The only remaining difference is the transfer of string descriptors. > You can prevent Linux from asking for them by editing usb_string() in > drivers/usb/core/message.c. Just make the function return -ENOMEM > unconditionally. That will stop the requests from going out. > > Alan Stern > Ok, I first edited the kernel to return -ENOMEM like you suggested but the UPS still disconnected. I then edited it again to re-add the 1060 byte request and the UPS still disconnected. I'm attaching the usbmon traces. If you need any additional info I'll do my best to provide it. Thanks, David [-- Attachment #2: mon3.txt.bz2 --] [-- Type: application/x-bzip, Size: 1620 bytes --] [-- Attachment #3: mon4.txt.bz2 --] [-- Type: application/x-bzip, Size: 1627 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-22 16:25 ` David Niklas @ 2021-11-22 20:13 ` Alan Stern 2021-11-22 21:29 ` Filipe Laíns 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2021-11-22 20:13 UTC (permalink / raw) To: David Niklas, Jiri Kosina, Benjamin Tissoires Cc: linux-kernel, linux-usb, linux-input On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote: > Ok, I first edited the kernel to return -ENOMEM like you suggested but > the UPS still disconnected. I then edited it again to re-add the 1060 > byte request and the UPS still disconnected. > > I'm attaching the usbmon traces. > If you need any additional info I'll do my best to provide it. Holy cow! I just realized what's going on. And these little changes we've been messing around with have nothing to do with it. For the first time, I looked at the timestamps in the usbmon traces. It turns out that the disconnects occur several seconds after the kernel retrieves the HID report descriptor from the device. Under normal conditions we would expect to see report packets coming in from the device, starting just a fraction of a second after the descriptor is received. But that isn't happening in the Linux traces, whereas it does happen in the Windows pcap log. I would guess that the UPS is programmed to disconnect itself electronically from the USB bus if it doesn't get any requests for reports within a couple of seconds. That certainly would explain what you've been seeing. I can't imagine why it would be programmed to behave this way, but companies have been known to do stranger things. As for why the kernel doesn't try to get the reports... That's a little harder to answer. Maybe Jiri or Benjamin will know something about it. The UPS's vendor ID is 0d9f (POWERCOM) and the product ID is 0004. Now, the drivers/hid/hid-quirks.c file contains a quirk entry for 0d9f:0002 (product POWERCOM_UPS), which is probably an earlier model of the same device, or a very similar device. This quirk entry is in the hid_ignore_list; it tells the HID core not to handle the device at all. I don't know why that quirk entry is present, and furthermore, it can't directly affect what is happening with your device because the product IDs are different. Still, it is an indication that something strange is going on behind the scenes. Perhaps there is no kernel driver for these UPS devices? Perhaps the intention is that some user program will handle all the communication when one of them is detected? A quick search on Google turns up usbhid-ups, part of Network USB Tools (NUT) -- maybe you need to install that package in order to use the device. I don't know what the full story is. With luck, Jiri or Benjamin can help more. Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-22 20:13 ` Alan Stern @ 2021-11-22 21:29 ` Filipe Laíns 2021-11-23 16:33 ` Benjamin Tissoires 0 siblings, 1 reply; 18+ messages in thread From: Filipe Laíns @ 2021-11-22 21:29 UTC (permalink / raw) To: Alan Stern, David Niklas, Jiri Kosina, Benjamin Tissoires Cc: linux-kernel, linux-usb, linux-input [-- Attachment #1: Type: text/plain, Size: 3087 bytes --] On Mon, 2021-11-22 at 15:13 -0500, Alan Stern wrote: > On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote: > > Ok, I first edited the kernel to return -ENOMEM like you suggested but > > the UPS still disconnected. I then edited it again to re-add the 1060 > > byte request and the UPS still disconnected. > > > > I'm attaching the usbmon traces. > > If you need any additional info I'll do my best to provide it. > > Holy cow! I just realized what's going on. And these little changes > we've been messing around with have nothing to do with it. > > For the first time, I looked at the timestamps in the usbmon traces. It > turns out that the disconnects occur several seconds after the kernel > retrieves the HID report descriptor from the device. Under normal > conditions we would expect to see report packets coming in from the > device, starting just a fraction of a second after the descriptor is > received. But that isn't happening in the Linux traces, whereas it does > happen in the Windows pcap log. > > I would guess that the UPS is programmed to disconnect itself > electronically from the USB bus if it doesn't get any requests for > reports within a couple of seconds. That certainly would explain what > you've been seeing. I can't imagine why it would be programmed to > behave this way, but companies have been known to do stranger things. > > As for why the kernel doesn't try to get the reports... That's a little > harder to answer. Maybe Jiri or Benjamin will know something about it. > > The UPS's vendor ID is 0d9f (POWERCOM) and the product ID is 0004. Now, > the drivers/hid/hid-quirks.c file contains a quirk entry for 0d9f:0002 > (product POWERCOM_UPS), which is probably an earlier model of the same > device, or a very similar device. This quirk entry is in the > hid_ignore_list; it tells the HID core not to handle the device at all. > > I don't know why that quirk entry is present, and furthermore, it can't > directly affect what is happening with your device because the product > IDs are different. Still, it is an indication that something strange is > going on behind the scenes. > > Perhaps there is no kernel driver for these UPS devices? Perhaps the > intention is that some user program will handle all the communication > when one of them is detected? A quick search on Google turns up > usbhid-ups, part of Network USB Tools (NUT) -- maybe you need to > install that package in order to use the device. > > I don't know what the full story is. With luck, Jiri or Benjamin can > help more. > > Alan Stern hid-generic should be able to handle these devices, but UPSes are much less tested than normal input peripherals, so it's not that surprising that there may be some unexpected weirdness. FWIW, I have two UPSes, one works OOTB and the other doesn't, I have been meaning to investigate the issue. However, David's case seems to me like a hardware quirk, but that's just my guess. Cheers, Filipe Laíns [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-22 21:29 ` Filipe Laíns @ 2021-11-23 16:33 ` Benjamin Tissoires 2021-11-24 3:12 ` David Niklas 0 siblings, 1 reply; 18+ messages in thread From: Benjamin Tissoires @ 2021-11-23 16:33 UTC (permalink / raw) To: Filipe Laíns Cc: Alan Stern, David Niklas, Jiri Kosina, lkml, Linux USB Mailing List, open list:HID CORE LAYER On Mon, Nov 22, 2021 at 10:35 PM Filipe Laíns <lains@archlinux.org> wrote: > > On Mon, 2021-11-22 at 15:13 -0500, Alan Stern wrote: > > On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote: > > > Ok, I first edited the kernel to return -ENOMEM like you suggested but > > > the UPS still disconnected. I then edited it again to re-add the 1060 > > > byte request and the UPS still disconnected. > > > > > > I'm attaching the usbmon traces. > > > If you need any additional info I'll do my best to provide it. > > > > Holy cow! I just realized what's going on. And these little changes > > we've been messing around with have nothing to do with it. > > > > For the first time, I looked at the timestamps in the usbmon traces. It > > turns out that the disconnects occur several seconds after the kernel > > retrieves the HID report descriptor from the device. Under normal > > conditions we would expect to see report packets coming in from the > > device, starting just a fraction of a second after the descriptor is > > received. But that isn't happening in the Linux traces, whereas it does > > happen in the Windows pcap log. > > > > I would guess that the UPS is programmed to disconnect itself > > electronically from the USB bus if it doesn't get any requests for > > reports within a couple of seconds. That certainly would explain what > > you've been seeing. I can't imagine why it would be programmed to > > behave this way, but companies have been known to do stranger things. > > > > As for why the kernel doesn't try to get the reports... That's a little > > harder to answer. Maybe Jiri or Benjamin will know something about it. I am not sure exactly what is going on there. There are a couple of things that come to my mind: - for quite some time now, we don't fetch all reports whenever we connect a new device. This was known to be problematic on some devices (see all the devices with HID_QUIRK_NOGET or HID_QUIRK_NO_INIT_REPORT), and the default to not poll input values on plug for devices is actually safer. If you want to revert, we will have to have a special driver for this one I guess - HID_QUIRK_ALWAYS_POLL *might* be a way to force the device to stay with a USB connection up. > > > > The UPS's vendor ID is 0d9f (POWERCOM) and the product ID is 0004. Now, > > the drivers/hid/hid-quirks.c file contains a quirk entry for 0d9f:0002 > > (product POWERCOM_UPS), which is probably an earlier model of the same > > device, or a very similar device. This quirk entry is in the > > hid_ignore_list; it tells the HID core not to handle the device at all. > > > > I don't know why that quirk entry is present, and furthermore, it can't > > directly affect what is happening with your device because the product > > IDs are different. Still, it is an indication that something strange is > > going on behind the scenes. > > > > Perhaps there is no kernel driver for these UPS devices? Perhaps the > > intention is that some user program will handle all the communication > > when one of them is detected? A quick search on Google turns up > > usbhid-ups, part of Network USB Tools (NUT) -- maybe you need to > > install that package in order to use the device. I don't have enough experience with UPS here to be helpful, unfortunately. But What Alan said made a lot of sense. Maybe the NUT people will have a better insight. > > > > I don't know what the full story is. With luck, Jiri or Benjamin can > > help more. > > > > Alan Stern > > hid-generic should be able to handle these devices, but UPSes are much less > tested than normal input peripherals, so it's not that surprising that there may > be some unexpected weirdness. FWIW, I have two UPSes, one works OOTB and the > other doesn't, I have been meaning to investigate the issue. However, David's > case seems to me like a hardware quirk, but that's just my guess. > Yep, that seems to validate the fact that this UPS needs some care... Cheers, Benjamin ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: I need advice with UPS connection. (ping) 2021-11-23 16:33 ` Benjamin Tissoires @ 2021-11-24 3:12 ` David Niklas 0 siblings, 0 replies; 18+ messages in thread From: David Niklas @ 2021-11-24 3:12 UTC (permalink / raw) To: Benjamin Tissoires Cc: Filipe Laíns, Alan Stern, Jiri Kosina, lkml, Linux USB Mailing List, open list:HID CORE LAYER On Tue, 23 Nov 2021 17:33:08 +0100 Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > On Mon, Nov 22, 2021 at 10:35 PM Filipe Laíns <lains@archlinux.org> > wrote: > > > > On Mon, 2021-11-22 at 15:13 -0500, Alan Stern wrote: > > > On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote: > > > > Ok, I first edited the kernel to return -ENOMEM like you > > > > suggested but the UPS still disconnected. I then edited it again > > > > to re-add the 1060 byte request and the UPS still disconnected. > > > > > > > > I'm attaching the usbmon traces. > > > > If you need any additional info I'll do my best to provide it. > > > > > > Holy cow! I just realized what's going on. And these little > > > changes we've been messing around with have nothing to do with it. > > > > > > For the first time, I looked at the timestamps in the usbmon > > > traces. It turns out that the disconnects occur several seconds > > > after the kernel retrieves the HID report descriptor from the > > > device. Under normal conditions we would expect to see report > > > packets coming in from the device, starting just a fraction of a > > > second after the descriptor is received. But that isn't happening > > > in the Linux traces, whereas it does happen in the Windows pcap log. > > > > > > I would guess that the UPS is programmed to disconnect itself > > > electronically from the USB bus if it doesn't get any requests for > > > reports within a couple of seconds. That certainly would explain > > > what you've been seeing. I can't imagine why it would be > > > programmed to behave this way, but companies have been known to do > > > stranger things. > > > > > > As for why the kernel doesn't try to get the reports... That's a > > > little harder to answer. Maybe Jiri or Benjamin will know > > > something about it. > > I am not sure exactly what is going on there. > There are a couple of things that come to my mind: > - for quite some time now, we don't fetch all reports whenever we > connect a new device. This was known to be problematic on some devices > (see all the devices with HID_QUIRK_NOGET or > HID_QUIRK_NO_INIT_REPORT), and the default to not poll input values on > plug for devices is actually safer. If you want to revert, we will > have to have a special driver for this one I guess > - HID_QUIRK_ALWAYS_POLL *might* be a way to force the device to stay > with a USB connection up. > > > > > > > The UPS's vendor ID is 0d9f (POWERCOM) and the product ID is 0004. > > > Now, the drivers/hid/hid-quirks.c file contains a quirk entry for > > > 0d9f:0002 (product POWERCOM_UPS), which is probably an earlier > > > model of the same device, or a very similar device. This quirk > > > entry is in the hid_ignore_list; it tells the HID core not to > > > handle the device at all. > > > > > > I don't know why that quirk entry is present, and furthermore, it > > > can't directly affect what is happening with your device because > > > the product IDs are different. Still, it is an indication that > > > something strange is going on behind the scenes. > > > > > > Perhaps there is no kernel driver for these UPS devices? Perhaps > > > the intention is that some user program will handle all the > > > communication when one of them is detected? A quick search on > > > Google turns up usbhid-ups, part of Network USB Tools (NUT) -- > > > maybe you need to install that package in order to use the device. > > I don't have enough experience with UPS here to be helpful, > unfortunately. But What Alan said made a lot of sense. Maybe the NUT > people will have a better insight. <snip> I'll send a message their way. Thanks, David ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-11-24 3:12 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-10 3:00 I need advice with UPS connection David Niklas 2020-11-10 21:55 ` Alan Stern 2020-11-11 1:17 ` Hgntkwis 2020-11-11 15:42 ` Alan Stern 2021-11-14 19:48 ` I need advice with UPS connection. (ping) David Niklas 2021-11-14 21:14 ` Alan Stern 2021-11-15 3:02 ` David Niklas 2021-11-15 16:09 ` Alan Stern 2021-11-15 22:08 ` David Niklas 2021-11-17 5:23 ` David Niklas 2021-11-17 17:08 ` Alan Stern 2021-11-19 22:19 ` David Niklas 2021-11-21 2:54 ` Alan Stern 2021-11-22 16:25 ` David Niklas 2021-11-22 20:13 ` Alan Stern 2021-11-22 21:29 ` Filipe Laíns 2021-11-23 16:33 ` Benjamin Tissoires 2021-11-24 3:12 ` David Niklas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).