Bug 2019542 - latest kernel (5.14.14) doesn't let me log in (system is either hung or keyboard/mouse are frozen)
Summary: latest kernel (5.14.14) doesn't let me log in (system is either hung or keybo...
Status: CLOSED DUPLICATE of bug 2019788
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2021-11-02 19:12 UTC by Brian
Modified: 2021-11-03 12:56 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-11-03 12:52:24 UTC
Type: Bug

Attachments (Terms of Use)
journalctl -b -1 --no-hostname -k (83.47 KB, text/plain)
2021-11-02 19:12 UTC, Brian
no flags Details

Description Brian 2021-11-02 19:12:15 UTC
Created attachment 1839308 [details]
journalctl -b -1 --no-hostname -k

1. Please describe the problem:

I upgraded F34 to the latest kernel (5.14.14) and rebooted. When the computer reaches the login screen it completely freezes. Both the keyboard and mouse are unresponsive and I can't log in (or do anything else).

2. What is the Version-Release number of the kernel:

broken kernel: 5.14.14-200

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Yes, keyboard and mouse used to work. They continue to work if I boot into 5.14.11-200.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Boot into the latest kernel and wait for the screen to freeze.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

6. Are you running any modules that not shipped with directly Fedora's kernel?:


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

I think I've attached the right file, dmesg.txt.

Comment 1 Hans de Goede 2021-11-02 21:49:01 UTC
Hmm, ok, so this is a regression in 5.14.14 and newer which is most likely caused by:

I guess some XHCI controllers don't like 32 bit writes to that register?

Comment 2 Hans de Goede 2021-11-03 12:51:56 UTC
Note the commit which I guessed was causing this was wrong, now we know which commits really are the culprit, see:


We know which patches in 5.14.14 are causing this and they will be reverted for the next 5.14.y release, for now please stay with a kernel < 5.14.14 to work around this.

Comment 3 Hans de Goede 2021-11-03 12:52:24 UTC

*** This bug has been marked as a duplicate of bug 2019788 ***

Comment 4 Brian 2021-11-03 12:56:08 UTC
Thanks Hans!

Note You need to log in before you can comment on or make changes to this bug.