Bug 2019576 - No USB devices are detected
Summary: No USB devices are detected
Keywords:
Status: CLOSED DUPLICATE of bug 2019788
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 35
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-02 20:45 UTC by Peter Janes
Modified: 2021-11-03 12:52 UTC (History)
18 users (show)

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


Attachments (Terms of Use)
Elided journalctl logs (4.38 KB, text/plain)
2021-11-02 20:45 UTC, Peter Janes
no flags Details

Description Peter Janes 2021-11-02 20:45:54 UTC
Created attachment 1839371 [details]
Elided journalctl logs

1. Please describe the problem:

When booting Fedora 35 with the default kernel none of my USB devices are recognized, including a Logitech mouse and an external Seagate drive.


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

5.14.14-300.fc35


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 :

Worked in Fedora 34 up to the most recent patch.  In Fedora 35, the USB devices work after downgrading to 5.14.10-300.fc35.  I also found this similar issue that suggested a downgrade might work: https://bbs.archlinux.org/viewtopic.php?pid=2000112


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

Yes, with 5.14.14 and 5.14.15 (from updates-testing).

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``:

Yes.

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

Can reproduce without them.

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.

Attached.

Comment 1 Hans de Goede 2021-11-02 21:50:50 UTC
Hmm, ok, so this is a regression in 5.14.14 and newer which is most likely caused by:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.14.y&id=e54abefe703ab7c4e5983e889babd1447738ca42

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

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

https://lore.kernel.org/stable/42bcbea6-5eb8-16c7-336a-2cb72e71bc36@redhat.com/

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:21 UTC

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


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