* USB resets
@ 2021-04-20 7:17 Jorge Fernandez Monteagudo
2021-04-20 7:22 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Jorge Fernandez Monteagudo @ 2021-04-20 7:17 UTC (permalink / raw)
To: kernelnewbies
[-- Attachment #1.1: Type: text/plain, Size: 6569 bytes --]
Hi all,
I'm using an ancient 4.17.1 kernel and I'm seeing an weird USB behavior. A touchscreen device is been detected and disconnected in a 4 seconds pattern.
# dmesg | grep 1.3.2[ 2.170041] usb 1-1.3.2: new full-speed USB device number 6 using ehci-pci
[ 2.254868] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0001/input/input2
[ 2.254958] hid-multitouch 0003:29BD:4101.0001: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 6.776320] usb 1-1.3.2: USB disconnect, device number 6
[ 6.955040] usb 1-1.3.2: new full-speed USB device number 7 using ehci-pci
[ 7.039215] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0002/input/input4
[ 7.039306] hid-multitouch 0003:29BD:4101.0002: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 11.383830] usb 1-1.3.2: USB disconnect, device number 7
[ 11.642043] usb 1-1.3.2: new full-speed USB device number 8 using ehci-pci
[ 11.726858] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0003/input/input6
[ 11.726947] hid-multitouch 0003:29BD:4101.0003: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 16.247185] usb 1-1.3.2: USB disconnect, device number 8
[ 16.426042] usb 1-1.3.2: new full-speed USB device number 9 using ehci-pci
[ 16.510970] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0004/input/input8
[ 16.511067] hid-multitouch 0003:29BD:4101.0004: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 20.854572] usb 1-1.3.2: USB disconnect, device number 9
[ 21.112042] usb 1-1.3.2: new full-speed USB device number 10 using ehci-pci
[ 21.197973] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0005/input/input10
[ 21.198072] hid-multitouch 0003:29BD:4101.0005: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 25.717651] usb 1-1.3.2: USB disconnect, device number 10
[ 25.895018] usb 1-1.3.2: new full-speed USB device number 11 using ehci-pci
[ 25.979810] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0006/input/input12
[ 25.979909] hid-multitouch 0003:29BD:4101.0006: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 30.325789] usb 1-1.3.2: USB disconnect, device number 11
[ 30.588021] usb 1-1.3.2: new full-speed USB device number 12 using ehci-pci
[ 30.673335] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0007/input/input14
[ 30.673381] hid-multitouch 0003:29BD:4101.0007: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 35.188772] usb 1-1.3.2: USB disconnect, device number 12
[ 35.366040] usb 1-1.3.2: new full-speed USB device number 13 using ehci-pci
[ 35.451447] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0008/input/input16
[ 35.451498] hid-multitouch 0003:29BD:4101.0008: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 39.795933] usb 1-1.3.2: USB disconnect, device number 13
[ 40.055019] usb 1-1.3.2: new full-speed USB device number 14 using ehci-pci
[ 40.139578] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0009/input/input18
[ 40.139626] hid-multitouch 0003:29BD:4101.0009: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 44.659133] usb 1-1.3.2: USB disconnect, device number 14
[ 44.837018] usb 1-1.3.2: new full-speed USB device number 15 using ehci-pci
[ 44.920784] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000A/input/input20
[ 44.920828] hid-multitouch 0003:29BD:4101.000A: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 49.266523] usb 1-1.3.2: USB disconnect, device number 15
[ 49.550012] usb 1-1.3.2: new full-speed USB device number 16 using ehci-pci
[ 49.634659] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000B/input/input22
[ 49.634706] hid-multitouch 0003:29BD:4101.000B: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 54.129875] usb 1-1.3.2: USB disconnect, device number 16
[ 54.305025] usb 1-1.3.2: new full-speed USB device number 17 using ehci-pci
[ 54.390293] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000C/input/input24
[ 54.390342] hid-multitouch 0003:29BD:4101.000C: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 58.737665] usb 1-1.3.2: USB disconnect, device number 17
[ 58.996040] usb 1-1.3.2: new full-speed USB device number 18 using ehci-pci
[ 59.079931] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000D/input/input29
[ 59.079981] hid-multitouch 0003:29BD:4101.000D: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
[ 63.932020] usb 1-1.3.2: reset full-speed USB device number 18 using ehci-pci
After 12 disconnect messages sometime I see a reset message, like the shown in this trace, and the touch is not working. Sometime this reset it's not send and the touchs works ok. My guess is that the Xorg sometime runs and get access to touch before this 4 or 5 second watchdog is executed and then the touch is not disconnected this last time...
Anybody has some experience in this kind of USB errors? Is it a known behavior modified in a more recent kernel?
Any hint is welcome
Jorge
[-- Attachment #1.2: Type: text/html, Size: 8332 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB resets
2021-04-20 7:17 USB resets Jorge Fernandez Monteagudo
@ 2021-04-20 7:22 ` Greg KH
2021-04-20 7:41 ` Jorge Fernandez Monteagudo
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2021-04-20 7:22 UTC (permalink / raw)
To: Jorge Fernandez Monteagudo; +Cc: kernelnewbies
On Tue, Apr 20, 2021 at 07:17:10AM +0000, Jorge Fernandez Monteagudo wrote:
> Hi all,
>
> I'm using an ancient 4.17.1 kernel and I'm seeing an weird USB behavior. A touchscreen device is been detected and disconnected in a 4 seconds pattern.
>
> # dmesg | grep 1.3.2[ 2.170041] usb 1-1.3.2: new full-speed USB device number 6 using ehci-pci
> [ 2.254868] input: Silicon Works Multi-touch SW4101C as /devices/pci0000:00/0000:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0001/input/input2
> [ 2.254958] hid-multitouch 0003:29BD:4101.0001: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-0000:00:12.0-1.3.2/input0
> [ 6.776320] usb 1-1.3.2: USB disconnect, device number 6
Bad hardware, the kernel can not cause a disconnect :(
Do you have a flaky cable or underpowerd hub here?
thanks,
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: USB resets
2021-04-20 7:22 ` Greg KH
@ 2021-04-20 7:41 ` Jorge Fernandez Monteagudo
2021-04-20 8:52 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Jorge Fernandez Monteagudo @ 2021-04-20 7:41 UTC (permalink / raw)
To: Greg KH; +Cc: kernelnewbies
>Bad hardware, the kernel can not cause a disconnect :(
>
>Do you have a flaky cable or underpowerd hub here?
>
How many retries before the kernel decides to send a reset to a USB device? After a reset, this device is ignored?
Thanks!
Jorge
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB resets
2021-04-20 7:41 ` Jorge Fernandez Monteagudo
@ 2021-04-20 8:52 ` Greg KH
2021-04-22 7:32 ` Jorge Fernandez Monteagudo
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2021-04-20 8:52 UTC (permalink / raw)
To: Jorge Fernandez Monteagudo; +Cc: kernelnewbies
On Tue, Apr 20, 2021 at 07:41:14AM +0000, Jorge Fernandez Monteagudo wrote:
> >Bad hardware, the kernel can not cause a disconnect :(
> >
> >Do you have a flaky cable or underpowerd hub here?
> >
>
> How many retries before the kernel decides to send a reset to a USB device? After a reset, this device is ignored?
The hub itself disconnects the device electronically, the kernel does
not do that. When the device comes back, then it is initialized by the
kernel, as the logs show, but then it is disconnected again.
This really looks like broken hardware or electronic noise on the
connection, the kernel can not cause electronic disconnects on a USB hub
like this.
good luck!
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: USB resets
2021-04-20 8:52 ` Greg KH
@ 2021-04-22 7:32 ` Jorge Fernandez Monteagudo
2021-04-22 8:03 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Jorge Fernandez Monteagudo @ 2021-04-22 7:32 UTC (permalink / raw)
To: Greg KH; +Cc: kernelnewbies
[-- Attachment #1.1: Type: text/plain, Size: 1585 bytes --]
I've been able to stop the disconnecting loop.
First I tried the usbcore.autosuspend=-1 guessing that an inactive period of time will send the device to some low power state, explaining the enumerating and disconnect loop with, but I had no luck.
Then I force using the device with an udev rule running
evtest --query $DEVNAME EV_KEY 0
and the disconnection disappears. Maybe it's an error in the tobis touchscreen controller code??
I would like to test if the behavior changes in full speed instead of high speed. Is there some way to downgrade the EHCI speed to full speed?
Thanks!
________________________________
De: Greg KH <gregkh@linuxfoundation.org>
Enviado: martes, 20 de abril de 2021 10:52
Para: Jorge Fernandez Monteagudo <jorgefm@cirsa.com>
Cc: kernelnewbies@kernelnewbies.org <kernelnewbies@kernelnewbies.org>
Asunto: Re: USB resets
On Tue, Apr 20, 2021 at 07:41:14AM +0000, Jorge Fernandez Monteagudo wrote:
> >Bad hardware, the kernel can not cause a disconnect :(
> >
> >Do you have a flaky cable or underpowerd hub here?
> >
>
> How many retries before the kernel decides to send a reset to a USB device? After a reset, this device is ignored?
The hub itself disconnects the device electronically, the kernel does
not do that. When the device comes back, then it is initialized by the
kernel, as the logs show, but then it is disconnected again.
This really looks like broken hardware or electronic noise on the
connection, the kernel can not cause electronic disconnects on a USB hub
like this.
good luck!
greg k-h
[-- Attachment #1.2: Type: text/html, Size: 3832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: USB resets
2021-04-22 7:32 ` Jorge Fernandez Monteagudo
@ 2021-04-22 8:03 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2021-04-22 8:03 UTC (permalink / raw)
To: Jorge Fernandez Monteagudo; +Cc: kernelnewbies
On Thu, Apr 22, 2021 at 07:32:15AM +0000, Jorge Fernandez Monteagudo wrote:
> I've been able to stop the disconnecting loop.
>
> First I tried the usbcore.autosuspend=-1 guessing that an inactive period of time will send the device to some low power state, explaining the enumerating and disconnect loop with, but I had no luck.
>
> Then I force using the device with an udev rule running
>
> evtest --query $DEVNAME EV_KEY 0
>
> and the disconnection disappears. Maybe it's an error in the tobis touchscreen controller code??
Looks like the device is broken, sorry. Again, the kernel can not cause
an electrical disconnection like this.
> I would like to test if the behavior changes in full speed instead of high speed. Is there some way to downgrade the EHCI speed to full speed?
Plug in a USB 1 bus? if you can find such an old obsolete thing :)
good luck!
greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-22 8:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 7:17 USB resets Jorge Fernandez Monteagudo
2021-04-20 7:22 ` Greg KH
2021-04-20 7:41 ` Jorge Fernandez Monteagudo
2021-04-20 8:52 ` Greg KH
2021-04-22 7:32 ` Jorge Fernandez Monteagudo
2021-04-22 8:03 ` Greg KH
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).