Hi,
On 9/2/20 5:17 PM, Hans de Goede wrote:
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.
Ok, so having the xhci driver moved to being builtin again (it became a
module by accident because of the new XHCI_RENESAS Kconfig option)
resolves the issue for both users reporting this issue.
For 1 user this makes sense, because he needed the kbd in the initrd
and the xhci module was not being included.
For the other user, the original reporter of:
https://bugzilla.redhat.com/show_bug.cgi?id=1874300
this is not expected though, he does not need his kbd/mouse to boot,
and once at the gdm login screen then if xhci is a module or not
should not matter.
Upon re-reading his comments I think I got one part of this bug-report
wrong. He ran "lsusb -t" with his mouse + kbd in the non-working XHCI
ports, but he did so with a working kernel (if I'm reading the report
correctly this second reading). So I think that his mouse/kbd might
actually be not detected at all when plugged into xhci ports and
xhci is build as a module. To me that seems to make more sense
then interrupt-transfers not working.
My theory is that the ports are being turned off by the kernel when it
turns of unused ACPI power-resources before switching to the initrd;
and that for some reason they are not turned back-on when the XHCI
module loads.
Anyways for now building in the xhci module worksaround this, but
IMHO it would be good to get to the bottom of this issue.
Regards,
Hans
