Hi,
On 9/2/20 2:17 PM, Mathias Nyman wrote:
Hi
On 2.9.2020 12.07, Hans de Goede wrote:
Hi,
I've been working with 2 Fedora users who both report that there
keyboard and mouse has stopped working after upgrading to
5.7.17 -> 5.8.4 .
After some back and forth I have found the following common pattern:
1. Both reporters have a "9 Series Chipset Family USB xHCI Controller"
2. Both reporters have a lo-speed (1.5M) keyboard and mouse connected to
that XHCI controller
3. The kbd/mouse gets detected but does not send events.
So there seems to be an issue with lo-speed USB interrupt-transfers
not working on the "9 Series Chipset Family USB xHCI Controller".
One reporter is using a DELL Precicion T5610 laptop, the PCI id
of the XHCI controller there is 8086:8cb1 and both 5.7 and 5.8 dmesg say:
[ 3.324639] xhci_hcd 0000:00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x0000000000009810
[ 3.324643] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
Are there any logs of this?
Yes, sorry I should have included a bugzilla link, the bugzilla has
lsusb -t and dmesg out from both users with both kernels:
https://bugzilla.redhat.com/show_bug.cgi?id=1874300
But it seems that at least part of the problem is the xhci driver
being built as a module with the Fedora 5.8 kernels where as 5.7
had it builtin, so first let me investigate that angle further before
you spend more time on this.
Regards,
Hans
Dynamic debug of xhci and usb core would help.
echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control
The other reporter is using a Gigabyte H97-D3H motherboard. This reporter
reports that plugging the kbd/mouse into the USB ports which are connected
to the H97's EHCI controller works around the problem.
I have tried to reproduce this on some of my own systems, but I do
not have any hardware of this exact generation and I could not reproduce
it on the closest hardware which I do have.
Matthias, if you have some idea which 4.8 change might have caused this
I can build rpms with a test kernel with that change reverted for
the reporters to test.
Can't see anything obvious that would cause this on the xhci side.
Best guess would have been:
8f97250c21f0 xhci: Don't clear hub TT buffer on ep0 protocol stall
- but it's already in 5.7.17.
536dd97c6952 xhci: Fix enumeration issue when setting max packet size for FS devices
- but is for Full-speed devices, and also in 5.7.17
If there is a hub (possibly built in) between the roothub and the keyboard then this
could be related to the TT buffer of the hub. Just before 5.7 there were fixes related to this,
and would concern LS and FS devices.
what does lsusb -t say?
Are there any changes on the hid side that could case this?
-Mathias
