I'm now running fedora 31 on my system at home and at work. On both systems I occasionally notice all my xinput settings have reverted to default, as if I unplugged my mouse and plugged it back in (even though I didn't unplug it).
Has anyone else noticed USB weirdness like this? Looking at dmesg, that seems to be what the kernel thinks happened:
[ 36.142138] 8021q: 802.1Q VLAN Support v1.8 [ 36.188272] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s29u1u2: link becomes ready [28350.784597] usb 2-1-port5: disabled by hub (EMI?), re-enabling... [28350.784606] usb 2-1.5: USB disconnect, device number 4 [28350.979282] usb 2-1.5: new low-speed USB device number 6 using ehci-pci [28351.063350] usb 2-1.5: New USB device found, idVendor=047d, idProduct=1020, bcdDevice= 1.00 [28351.063355] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [28351.063358] usb 2-1.5: Product: Kensington Expert Mouse [28351.063360] usb 2-1.5: Manufacturer: Kensington [28351.066182] input: Kensington Kensington Expert Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:047D:1020.0005/input/input21 [28351.066409] hid-generic 0003:047D:1020.0005: input,hidraw1: USB HID v1.10 Mouse [Kensington Kensington Expert Mouse] on usb-0000:00:1d.0-1.5/input0
Looks like a little less than 8 hours after the booted, the kernel decided I just disconnected and reconnected the mouse.
I have no idea what an EMI is, but that's what starts everything.
On 18.11.19 21:46, Tom Horsley wrote: ...
I have no idea what an EMI is, but that's what starts everything.
I guess it is "electromagnetic interference"
https://en.wikipedia.org/wiki/Electromagnetic_interference
I have had 2 laptop USB ports die slowly (all ports slowly got flakier, until the caused slowness issues from seemingly random interrupts). I suspected it to be heat and poor cooling design around the usb chips. So far 2 previous models slowly (not from the same labeled provider) became less and less stable with disconnects more and more often.
On Mon, Nov 18, 2019 at 2:47 PM Tom Horsley horsley1953@gmail.com wrote:
I'm now running fedora 31 on my system at home and at work. On both systems I occasionally notice all my xinput settings have reverted to default, as if I unplugged my mouse and plugged it back in (even though I didn't unplug it).
Has anyone else noticed USB weirdness like this? Looking at dmesg, that seems to be what the kernel thinks happened:
[ 36.142138] 8021q: 802.1Q VLAN Support v1.8 [ 36.188272] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s29u1u2: link becomes ready [28350.784597] usb 2-1-port5: disabled by hub (EMI?), re-enabling... [28350.784606] usb 2-1.5: USB disconnect, device number 4 [28350.979282] usb 2-1.5: new low-speed USB device number 6 using ehci-pci [28351.063350] usb 2-1.5: New USB device found, idVendor=047d, idProduct=1020, bcdDevice= 1.00 [28351.063355] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [28351.063358] usb 2-1.5: Product: Kensington Expert Mouse [28351.063360] usb 2-1.5: Manufacturer: Kensington [28351.066182] input: Kensington Kensington Expert Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:047D:1020.0005/input/input21 [28351.066409] hid-generic 0003:047D:1020.0005: input,hidraw1: USB HID v1.10 Mouse [Kensington Kensington Expert Mouse] on usb-0000:00:1d.0-1.5/input0
Looks like a little less than 8 hours after the booted, the kernel decided I just disconnected and reconnected the mouse.
I have no idea what an EMI is, but that's what starts everything. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Mon, 18 Nov 2019 at 17:24, fedorauser@online.de fedorauser@online.de wrote:
On 18.11.19 21:46, Tom Horsley wrote: ...
I have no idea what an EMI is, but that's what starts everything.
I guess it is "electromagnetic interference"
Correct. From hub.c https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c
/* * EM interference sometimes causes badly shielded USB devices * to be shutdown by the hub, this hack enables them again. * Works at least with mouse driver. */ if (!(portstatus & USB_PORT_STAT_ENABLE)&& !connect_change && udev) { dev_err(&port_dev->dev, "disabled by hub (EMI?), re-enabling...\n"); connect_change = 1; }
USB3 devices can be sources of EMI.
[...]
On Mon, 18 Nov 2019 at 21:06, Roger Heflin rogerheflin@gmail.com wrote:
I have had 2 laptop USB ports die slowly (all ports slowly got flakier, until the caused slowness issues from seemingly random interrupts). I suspected it to be heat and poor cooling design around the usb chips. So far 2 previous models slowly (not from the same labeled provider) became less and less stable with disconnects more and more often.
Are these problems associated with addition of USB3 devices?
[...]
On Mon, 2019-11-18 at 21:07 -0400, George N. White III wrote:
Correct. From hub.c
/*
- EM interference sometimes causes badly shielded USB devices
- to be shutdown by the hub, this hack enables them again.
- Works at least with mouse driver.
*/ if (!(portstatus & USB_PORT_STAT_ENABLE)&& !connect_change && udev) { dev_err(&port_dev->dev, "disabled by hub (EMI?), re- enabling...\n"); connect_change = 1; }
USB3 devices can be sources of EMI.
You could have a mouse with unshielded wiring, some cheap mice give scant regard to good building practices. And you could have a tiny cable break due to metal fatigue.
I was forever getting logs about a mouse disconnecting. In my case, it's one of the mice that perpetually goes into a sleep mode when untouched, this upsets the system, which immediately wakes it up again.
Everyone seems to have ignored the important bits of info in my original post: This only started happening when I installed fedora 31, and it started happening on two separate systems the same way :-).
The mice worked for years with no problems before f31.
On 19.11.19 13:59, Tom Horsley wrote:
Everyone seems to have ignored the important bits of info in my original post: This only started happening when I installed fedora 31, and it started happening on two separate systems the same way :-).
The mice worked for years with no problems before f31. _______________________________________________
Yup, I did ! I'm somewhat hot trying to fix *your* problems. Should I fix that too ?
;-)
and what an lie: nobody could fetch that your USB was running on F30 !
Please be honest! you simply didn't notice it on F30, now F31 is to blame.
damn, damn F31...
I guess it has something to do with the *Expert* Mouse, it needs to be "Advanced Expert" for F31 !
:-)
On 11/19/19 8:59 PM, Tom Horsley wrote:
Everyone seems to have ignored the important bits of info in my original post: This only started happening when I installed fedora 31, and it started happening on two separate systems the same way :-).
The mice worked for years with no problems before f31.
I do not see any problems here. 3 systems have Kensington Expert Wireless TB Mouse and utilize the Logitech Unifying Device for connectivity. So, no wires. Other systems use BT mice.
If I do unplug/plug the UD the mouse reconnects and indicates
new full-speed USB device number 6 using ehci-pci
I wonder why yours shows as low-speed USB device. Just curious.
On Tue, 19 Nov 2019 21:56:05 +0800 Ed Greshko wrote:
I wonder why yours shows as low-speed USB device. Just curious.
Because it is plugged into a usb2 port to leave usb3 port free for stuff that needs them. These are both wired mice, not wireless.
I was wondering if maybe older kernels used to reconnect silently so no one noticed the port problem. That would explain why I never saw it before (because it is hard to miss when my button reprogramming disappears and drag lock stops working :-).
On 11/19/19 10:05 PM, Tom Horsley wrote:
On Tue, 19 Nov 2019 21:56:05 +0800 Ed Greshko wrote:
I wonder why yours shows as low-speed USB device. Just curious.
Because it is plugged into a usb2 port to leave usb3 port free for stuff that needs them. These are both wired mice, not wireless.
Hummm....
These machines are rather old. When I run "lsusb -v" and grep on bcdUSB they all show 2.00. So, I don't think I have any USB3 ports. Still I see full-speed USB reported.
I'm pretty sure bcdUSB indicates the version since an even older laptop has 2.00 and 1.10.
I was wondering if maybe older kernels used to reconnect silently so no one noticed the port problem. That would explain why I never saw it before (because it is hard to miss when my button reprogramming disappears and drag lock stops working :-).
Not that I know of. Other than the one time a kernel update caused some mice not to be recognized I've never had a problem.
On Tue, 19 Nov 2019 at 10:06, Tom Horsley horsley1953@gmail.com wrote:
On Tue, 19 Nov 2019 21:56:05 +0800 Ed Greshko wrote:
I wonder why yours shows as low-speed USB device. Just curious.
Because it is plugged into a usb2 port to leave usb3 port free for stuff that needs them. These are both wired mice, not wireless.
I was wondering if maybe older kernels used to reconnect silently so no one noticed the port problem. That would explain why I never saw it before (because it is hard to miss when my button reprogramming disappears and drag lock stops working :-).
The EFI message was introduced long ago. Has USB3 port usage changed since you upgraded to Fedora 31?
On Tue, 19 Nov 2019 14:42:51 -0400 George N. White III wrote:
The EFI message was introduced long ago. Has USB3 port usage changed since you upgraded to Fedora 31?
Nope. The only thing different on both these systems is fedora 31. At least it only happens every few hours (or even days), so it isn't constantly changing my mouse buttons and it is easy to re-run the xinput commands I have in a script when it does happen.
On Tue, 19 Nov 2019 at 14:58, Tom Horsley horsley1953@gmail.com wrote:
On Tue, 19 Nov 2019 14:42:51 -0400 George N. White III wrote:
The EFI message was introduced long ago. Has USB3 port usage changed since you upgraded to Fedora 31?
Nope. The only thing different on both these systems is fedora 31. At least it only happens every few hours (or even days), so it isn't constantly changing my mouse buttons and it is easy to re-run the xinput commands I have in a script when it does happen.\
EFI is looking like a red herring. Next on the list of suspects with access to both systems is power management. Have a look at USB Power Management for Linux 5.3 https://www.kernel.org/doc/html/v5.3/driver-api/usb/power-management.html (hasn't changed over many kernel versions). A good first step would be to disable USB PM and see if the issue goes away.
Although USB PM has been fairly stable, power management changes https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-Ice-Lake-PM-USB are being made in other parts of the kernel, so collateral damage is a possibility.
On Tue, 19 Nov 2019 18:42:31 -0400 George N. White III wrote:
EFI is looking like a red herring. Next on the list of suspects with access to both systems is power management. Have a look at USB Power Management for Linux 5.3 https://www.kernel.org/doc/html/v5.3/driver-api/usb/power-management.html (hasn't changed over many kernel versions). A good first step would be to disable USB PM and see if the issue goes away.
Thanks! That sounds like useful info. The kernel already had the mouse set to not ever suspend, but backing up to the hub, I see it set to "auto", so I disabled the hub PM and I'll see if I notice the mouse go away again.
On 11/18/19 12:46 PM, Tom Horsley wrote:
I'm now running fedora 31 on my system at home and at work. On both systems I occasionally notice all my xinput settings have reverted to default, as if I unplugged my mouse and plugged it back in (even though I didn't unplug it).
Has anyone else noticed USB weirdness like this? Looking at dmesg, that seems to be what the kernel thinks happened:
[ 36.142138] 8021q: 802.1Q VLAN Support v1.8 [ 36.188272] IPv6: ADDRCONF(NETDEV_CHANGE): wlp0s29u1u2: link becomes ready [28350.784597] usb 2-1-port5: disabled by hub (EMI?), re-enabling... [28350.784606] usb 2-1.5: USB disconnect, device number 4 [28350.979282] usb 2-1.5: new low-speed USB device number 6 using ehci-pci [28351.063350] usb 2-1.5: New USB device found, idVendor=047d, idProduct=1020, bcdDevice= 1.00 [28351.063355] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [28351.063358] usb 2-1.5: Product: Kensington Expert Mouse [28351.063360] usb 2-1.5: Manufacturer: Kensington [28351.066182] input: Kensington Kensington Expert Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/0003:047D:1020.0005/input/input21 [28351.066409] hid-generic 0003:047D:1020.0005: input,hidraw1: USB HID v1.10 Mouse [Kensington Kensington Expert Mouse] on usb-0000:00:1d.0-1.5/input0
Looks like a little less than 8 hours after the booted, the kernel decided I just disconnected and reconnected the mouse.
I have no idea what an EMI is, but that's what starts everything.
Hi Tom,
Probably not what you asked, but when does that stop me?
Is this a "add on" USB card? I have the worst luck with add on USB cards in both Windows and Linux. My shop computer has an add on USB 3.1 card that is a one shot card: I can read a flash drive from it once. After I eject the flash drive, I have to reboot to get it to work again. And this was the forth card I tested. The first three just corrupted the data or blew out.
Never have any issue with the USB ports on the motherboard. Are the malfunction port(s) on your motherboard?
-T
On Tue, 19 Nov 2019 15:28:04 -0800 ToddAndMargo via users wrote:
Never have any issue with the USB ports on the motherboard. Are the malfunction port(s) on your motherboard?
On the motherboard on both systems. I've tried disabling the USB power management on the hub and I'll see what that does.
On 11/19/19 3:49 PM, Tom Horsley wrote:
On Tue, 19 Nov 2019 15:28:04 -0800 ToddAndMargo via users wrote:
Never have any issue with the USB ports on the motherboard. Are the malfunction port(s) on your motherboard?
On the motherboard on both systems. I've tried disabling the USB power management on the hub and I'll see what that does.
Okay, I have seen that on ps/2 to USB converters. Lights flash on the ps/2 keyboard every so often. Never lost my settings though.
Also, have you tried other mice/keyboards from other manufacturer? I would be really suspicious of your peripheral hardware at this point.
On Tue, 19 Nov 2019 16:38:33 -0800 ToddAndMargo via users wrote:
Also, have you tried other mice/keyboards from other manufacturer? I would be really suspicious of your peripheral hardware at this point.
I've used these for years, and this only started happening when fedora 31 was installed on both systems. Hardware seems really unlikely to me.
On 20191119 15:04:58, Tom Horsley wrote:
On Tue, 19 Nov 2019 18:42:31 -0400 George N. White III wrote:
EFI is looking like a red herring. Next on the list of suspects with access to both systems is power management. Have a look at USB Power Management for Linux 5.3 https://www.kernel.org/doc/html/v5.3/driver-api/usb/power-management.html (hasn't changed over many kernel versions). A good first step would be to disable USB PM and see if the issue goes away.
Thanks! That sounds like useful info. The kernel already had the mouse set to not ever suspend, but backing up to the hub, I see it set to "auto", so I disabled the hub PM and I'll see if I notice the mouse go away again.
Another thing that comes to mind, that I have seen, is a flaky USB cable. Flexing it would cause a USB reset for the device. And mice seem to get a lot of flexing due a lot of movement. {o.o}
On 11/19/19 4:50 PM, Tom Horsley wrote:
On Tue, 19 Nov 2019 16:38:33 -0800 ToddAndMargo via users wrote:
Also, have you tried other mice/keyboards from other manufacturer? I would be really suspicious of your peripheral hardware at this point.
I've used these for years, and this only started happening when fedora 31 was installed on both systems. Hardware seems really unlikely to me.
Dig into the archives and make yourself a Fedora 30 Live USB stick. See if the problem reoccurs.
I am seeing it occurring on the new kernels on f30, so the kernel does seem what is doing it.
I was figuring another new laptop was in my future.
On Tue, Nov 19, 2019 at 10:23 PM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 11/19/19 4:50 PM, Tom Horsley wrote:
On Tue, 19 Nov 2019 16:38:33 -0800 ToddAndMargo via users wrote:
Also, have you tried other mice/keyboards from other manufacturer? I would be really suspicious of your peripheral hardware at this point.
I've used these for years, and this only started happening when fedora 31 was installed on both systems. Hardware seems really unlikely to me.
Dig into the archives and make yourself a Fedora 30 Live USB stick. See if the problem reoccurs.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On Wed, 20 Nov 2019 at 17:41, Roger Heflin rogerheflin@gmail.com wrote:
I am seeing it occurring on the new kernels on f30, so the kernel does seem what is doing it.
xhci has a bug affecting many USB devices across many hardware configurations and kernels 4.20 and later. https://bugzilla.kernel.org/show_bug.cgi?id=202541#c49 is one comment (out of more than 100) with USB mouse and keyboard getting reset after the " disabled by hub (EMI?), re-enabling..." message.
The majority of reports are for WiFi devices. I've often seen keyboard briefly stop responding and lights flash but never bothered to investigate. WiFi, like the OP's trackball, needs some configuration after a reset, so raises a slightly annoying bug for some devices to something serious for others. All this suggests something common to multiple usb drivers that changed between 4.19 and 4.20.
I was figuring another new laptop was in my future.
New hardware, especially laptops, just introduces hardware that requires new, unproven, drivers. I've had the best luck with 2-3 years old laptops.
On Tue, Nov 19, 2019 at 10:23 PM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 11/19/19 4:50 PM, Tom Horsley wrote:
On Tue, 19 Nov 2019 16:38:33 -0800 ToddAndMargo via users wrote:
Also, have you tried other mice/keyboards from other manufacturer? I would be really suspicious of your peripheral hardware at this point.
I've used these for years, and this only started happening when fedora 31 was installed on both systems. Hardware seems really unlikely to me.
Dig into the archives and make yourself a Fedora 30 Live USB stick. See if the problem reoccurs.
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
-
Ed Greshko -
fedorauser＠online.de -
George N. White III -
jdow -
Roger Heflin -
sixpack13
-
Tim -
ToddAndMargo -
Tom Horsley