1. Please describe the problem: USB hotplug does not work with this and newer kernel versions. Nothing happens after plugging in e.g. a usb thumb drive (no new output in dmesg). HW is an AMD based Thinkpad T495s. 2. What is the Version-Release number of the kernel: 6.5.12-300.fc39.x86_64 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 : Working until kernel-6.5.10-300.fc39.x86_64 Broken since kernel-6.5.12-300.fc39.x86_64 Also broken with kernel-6.6.2-201.fc39.x86_64 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: USB hotplug on T495s. 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``: Also broken with kernel-6.6.2-201.fc39.x86_64 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 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. The logs from below are obtained from kernel-6.5.10-300 there is nothing in the logs and no error message with kernel-6.5.12-300 Expected journal output: Nov 26 17:40:43 schleppi kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk Nov 26 17:40:43 schleppi kernel: sda: sda1 sda2 Nov 26 17:40:43 schleppi kernel: sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Nov 26 17:40:43 schleppi kernel: sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08 Nov 26 17:40:43 schleppi kernel: sd 0:0:0:0: [sda] Write Protect is off Nov 26 17:40:43 schleppi kernel: sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB) Nov 26 17:40:43 schleppi kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0 Nov 26 17:40:43 schleppi kernel: scsi 0:0:0:0: Direct-Access SanDisk ExtremePro 0001 PQ: 0 ANSI: 6 Nov 26 17:40:42 schleppi mtp-probe[2154]: bus: 3, device: 3 was not an MTP device Nov 26 17:40:42 schleppi mtp-probe[2154]: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb3/3-2" Nov 26 17:40:42 schleppi mtp-probe[2153]: bus: 3, device: 3 was not an MTP device Nov 26 17:40:42 schleppi mtp-probe[2153]: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.3/usb3/3-2" Nov 26 17:40:42 schleppi kernel: scsi host0: usb-storage 3-2:1.0 Nov 26 17:40:42 schleppi kernel: usb-storage 3-2:1.0: USB Mass Storage device detected Nov 26 17:40:42 schleppi kernel: usb 3-2: SerialNumber: AA011021151131080519 Nov 26 17:40:42 schleppi kernel: usb 3-2: Manufacturer: SanDisk Nov 26 17:40:42 schleppi kernel: usb 3-2: Product: ExtremePro Nov 26 17:40:42 schleppi kernel: usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 26 17:40:42 schleppi kernel: usb 3-2: New USB device found, idVendor=0781, idProduct=5588, bcdDevice= 0.10 Nov 26 17:40:42 schleppi kernel: usb 3-2: new SuperSpeed USB device number 3 using xhci_hcd Reproducible: Always
Created attachment 2001551 [details] dmesg output
No events following a usb hotplug in udevadm monitor.
This sounds related to BUG #2251502 but it's not happening on my H/W.
Could not repro this using upstream 6.7-rc3 kernel.
This is reproducible using upstream stable 6.5.12 - I'll start bisecting.
Bisect pointed to 7b8ae3c24 ("xhci: Loosen RPM as default policy to cover for AMD xHC 1.1") that's commit 4baf12181509 in upstream linux Reverting that from 6.5.12 fixes the issue for me. I'll report the thing upstream.
https://lkml.org/lkml/2023/11/28/688
Ok, there's another upstream patch that is a proper fix for this and was missed during stable backports: a5d6264b ("xhci: Enable RPM on controllers that support low-power states"). Cherry-picking that on top of v6.5.12 fixes the issue for me. According to Greg KH this patch is already queued up for the next stable releases. I guess this will be fixed for fedora kernel via the next stable update.
FEDORA-2023-15deb2e32a has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-15deb2e32a
FEDORA-2023-a7b89262c6 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a7b89262c6
The mentioned patch made its way into the stable branches. kernel-6.6.3-200.fc39.x86_64 fixes the issue for me.
FEDORA-2023-15deb2e32a has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-15deb2e32a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-15deb2e32a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-a7b89262c6 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a7b89262c6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a7b89262c6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-a7b89262c6 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-15deb2e32a has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.