Created attachment 1802123 [details] dmesg for running (failing) kernel 1. Please describe the problem: Renesas USB 3.0 hub/controller fails to initialise with newest kernels 2. What is the Version-Release number of the kernel: kernel-5.12.17-300.fc34.x86_64 and kernel-5.13.2-300.fc34.x86_64 both exhibit the problem 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 correctly in kernel-5.2.15-300.fc34.x86_64 and kernel-5.13.1-300.fc34.x86_64 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Boot kernel-5.12.17 or kernel-5.13.2, USB 3.0 hub/controller and attached devices fail to be detected. 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``: No later kernels available 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.
Suspected commit from kernel.org changelog that is responsible for this regression: commit 2408318b5db59b0c80ed71d6f9eacf5b13c9501c Author: Moritz Fischer <mdf> Date: Tue Jun 15 08:37:58 2021 -0700 usb: renesas-xhci: Fix handling of unknown ROM state commit d143825baf15f204dac60acdf95e428182aa3374 upstream. The ROM load sometimes seems to return an unknown status (RENESAS_ROM_STATUS_NO_RESULT) instead of success / fail. If the ROM load indeed failed this leads to failures when trying to communicate with the controller later on. Attempt to load firmware using RAM load in those cases. Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Cc: stable.org Cc: Mathias Nyman <mathias.nyman> Cc: Greg Kroah-Hartman <gregkh> Cc: Vinod Koul <vkoul> Tested-by: Vinod Koul <vkoul> Reviewed-by: Vinod Koul <vkoul> Signed-off-by: Moritz Fischer <mdf> Link: https://lore.kernel.org/r/20210615153758.253572-1-mdf@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh>
Yes, looking at rc1, it is possible that this patch is actually dependent on another. Can you boot https://koji.fedoraproject.org/koji/buildinfo?buildID=1780011 and see if that fixes the issue? kernel-5.14.0-0.rc1.16.fc35
Created attachment 1802459 [details] dmesg for 5.14.0rc kernel from rawhide Tried the suggested 5.14.0rc series kernel, this also fails in the same way with the same Renesas firmware load failure.
Just in case I have to go do family things before it finishes, I have a scratch build going at: https://koji.fedoraproject.org/koji/taskinfo?taskID=72025669 Please test when it finishes and let me know if that resolves the issue.
Looks like it finished.
OK, now running kernel-5.13.2-301 as suggested, my Renesas USB 3.0 hub and connected devices are now working again. Not sure exactly what the change was, unless it was just dropping the problematic patch, but I assume this will get fed back upstream for further consideration. Thanks for the help.
Yes, I simply reverted the one patch. I just needed some testing feedback before I could send it upstream.
Kernel-5.13.2-301 fixed Renesas USB 3.0 Host Controller issues on my T14s AMD Generation_1 too.
Can you give https://koji.fedoraproject.org/koji/taskinfo?taskID=72194208 a try when it finishes? We know the revert works, but it leaves other systems broken, this one has a test patch which might work for all. Trying to get this worked out before the 5.13 rebase.
Right, tried this updated patch and it is working for me on the system I noticed the problem with. I will also try it on my other older machine which has a similar USB 3.0 card in it and report if I see any problem. Thanks for your help.
Kernel 5.13.3-300.fc34.x86_64 works for me too.
kernel-5.13.3-200.fc34.x86_64 is also good for me with fully working USB hubs.
Interesting to see that the firmware load failure message is still there in dmesg with the updated patch applied.
*** Bug 1984084 has been marked as a duplicate of this bug. ***
It makes sense. The controller doesn't require you to load a firmware. The patch that broke things didn't consider that case. 5.13.4 should also have the fix.
Thing is, I could agree with your view if the dmesg output was only there if a firmware load was needed. Previously it worked for me and I had no failure message at all because nothing actually failed to work. Now it works again but tells me something has failed. Maybe it's the controller's fault because it doesn't correctly indicate its status. This is what I get in dmesg [ 1.088779] xhci_hcd 0000:04:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2 [ 1.088784] xhci_hcd 0000:04:00.0: request_firmware failed: -2 [ 1.088902] xhci_hcd 0000:04:00.0: xHCI Host Controller [ 1.089004] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 3 lines 3 and 4 say the controller initialised and a bus was registered, but lines 1 and 2 suggest there is a problem. Maybe if we knew what error -2 meant it could be screened out, perhaps it means "I've got ROM firmware!"
So upstream has reverted the original patch now, though the author is planning to add it back with some variation of the patch we tested above. If issues arise when this happens, please reopen this bug since it contains the relevant history. I am going to close it out for now.
With 5.13.4, I'm getting this: [ 3.109800] xhci_hcd 0000:05:00.0: Direct firmware load for renesas_usb_fw.mem failed with error -2 [ 3.113185] xhci_hcd 0000:05:00.0: request_firmware failed: -2 [ 3.116694] xhci_hcd 0000:05:00.0: xHCI Host Controller [ 3.120123] xhci_hcd 0000:05:00.0: new USB bus registered, assigned bus number 4 [ 3.128734] xhci_hcd 0000:05:00.0: hcc params 0x014051cf hci version 0x100 quirks 0x0000001100000090 This is confusing. Is there an error or isn't there? It doesn't look like there is such firmware file included in linux-firmware, either: $ rpm -ql linux-firmware|grep renesas $