[Solved] USB3 stopped working with 5.13.6-arch1-1 again

BollerwagenPicard · 2021-07-30 10:08:10

Hi all

I am having problems with my USB3 PCIe expansion card again with the latest kernel. It is a Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03).
Last time I solved the problem by installing upd72020x-fw from the AUR, but this time it does not help. I have tried to do a

pikaur -S upd72020x-fw --rebuild

, but it does not help.

dmesg shows me this:

[    8.913840] xhci_hcd 0000:04:00.0: xHCI Host Controller
[    8.913852] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 3
[   18.913900] xhci_hcd 0000:04:00.0: can't setup: -110
[   18.914395] xhci_hcd 0000:04:00.0: USB bus 3 deregistered
[   18.914519] xhci_hcd 0000:04:00.0: init 0000:04:00.0 fail, -110
[   18.915070] xhci_hcd: probe of 0000:04:00.0 failed with error -110

lsmod | grep xhci
xhci_pci               20480  0
xhci_pci_renesas       20480  1 xhci_pci

Do you know a way to fix that and get it working with the current kernel?
If you need any information to help me, please feel free to ask.

Thank you for your help

Last edited by BollerwagenPicard (2021-08-01 09:53:05)

progandy · 2021-07-30 10:26:47

What is the last working kernel version?

BollerwagenPicard · 2021-07-30 10:31:27

it worked with 5.13.5.arch1-1 and upd72020x-fw from AUR
only 5.13.5.arch1-1 did not work

I do not know when it had stopped working before and I had to add upd72020x-fw.

Update1:
I have read in this bug https://bugs.archlinux.org/task/71570 report it is supposed to work again in the 5.13.6 now without the firmware files and have accordingly removed the AUR package. This has not solved the problem and I have installed it again.

Update2:
i have tested booting with usbcore.autosuspend=-1 set... but it did nothing for my problem.

Last edited by BollerwagenPicard (2021-07-30 11:09:35)

loqs · 2021-07-30 11:56:25

This was unfortunately expected as 5.13.6 contains https://git.kernel.org/pub/scm/linux/ke … db5d268d4e

BollerwagenPicard · 2021-07-30 12:10:20

Sorry @loqs, but I don't quite understand your answer . When I built the system, the USB ports worked without the firmware files from the AUR. Then there was an update and they stopped working, which I was able to solve using the AUR package. Now the developers have made a revert of the changes, shouldn't it work again without firmware files or am I too confused?

loqs · 2021-07-30 12:29:45

Could the module and firmware still be in the initrd?

BollerwagenPicard · 2021-07-30 12:37:51

I do not think so, as I got an error for missing firmware at mkinitcpio -P after removing the package from the system.
I'm not sure if I had it before the problem started... but it was definitely new after upd72020x-fw was removed.

mnd999 · 2021-07-30 15:15:11

I'm kinda finding xhci is just broken in this kernel (5.13.6-arch1-1) - I've been getting the following repeatedly all day:

[ 3161.790986] xhci_hcd 0000:0d:00.0: ERROR unknown event type 15
[ 3166.803237] xhci_hcd 0000:0d:00.0: xHCI host not responding to stop endpoint command.
[ 3166.803246] xhci_hcd 0000:0d:00.0: USBSTS: HCHalted
[ 3166.803267] xhci_hcd 0000:0d:00.0: xHCI host controller not responding, assume dead
[ 3166.803296] xhci_hcd 0000:0d:00.0: HC died; cleaning up

Workaround is to do this over ssh which makes the keyboard and mouse work again:

rmmod xhci_pci
modprobe xhci_pci

Last edited by mnd999 (2021-07-30 15:16:10)

drishal · 2021-07-31 05:39:46

Similar issue here, thinkpad P14s AMD. Had to install upd72020x-fw to get it working til 5.13.5, but it no longer works with 5.13.6 (for me its the webcam which broke, with no devices found and no /dev/video*, but the other USB ports did not break)

very similar logs as OP

[    5.411504] pci 0000:06:00.0: xHCI HW not ready after 5 sec (HC bug?) status = 0x1801
[    6.978101] xhci_hcd 0000:06:00.0: xHCI Host Controller
[    6.978108] xhci_hcd 0000:06:00.0: new USB bus registered, assigned bus number 2
[    6.978124] xhci_hcd 0000:06:00.0: Zeroing 64bit base registers, expecting fault
[   17.012352] xhci_hcd 0000:06:00.0: can't setup: -110
[   17.012379] xhci_hcd 0000:06:00.0: USB bus 2 deregistered
[   17.012459] xhci_hcd 0000:06:00.0: init 0000:06:00.0 fail, -110

and I had to give 2 online tests on my dad's windoze laptop because of no webcam

Last edited by drishal (2021-07-31 05:42:51)

progandy · 2021-07-31 06:23:04

It is strange that it doesn't work without firmware anymore.

Anyways as a temporary fix downgrade the kernel or try: https://github.com/markusj/upd72020x-load

BollerwagenPicard · 2021-07-31 13:51:52

do you think it will be fixed again in some of the next kernels?

Stargatto · 2021-07-31 15:15:05

Same problem here. Tried linux-lts (5.10.54-1-lts) with and without upd72020x-fw package, but it still returns the error (and no USB 3.0 devices are working)

[  377.983720] xhci_hcd 0000:04:00.0: xHCI Host Controller
[  377.983735] xhci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 8
[  387.983762] xhci_hcd 0000:04:00.0: can't setup: -110
[  387.983768] xhci_hcd 0000:04:00.0: USB bus 8 deregistered
[  387.983858] xhci_hcd 0000:04:00.0: init 0000:04:00.0 fail, -110
[  387.985235] xhci_hcd: probe of 0000:04:00.0 failed with error -110

progandy · 2021-07-31 15:31:28

Stargatto wrote:

Same problem here. Tried linux-lts (5.10.54-1-lts)

The revert has been backported to v5.10.54 as well: https://git.kernel.org/pub/scm/linux/ke … de9ce9ea9a

Has it ever worked without upd72020x-fw? If so the only two ideas that come to mind are that either using the firmware loaded to RAM somehow damaged the fixed version from ROM, or the driver has changed and doesn't work with the ROM version anymore.

do you think it will be fixed again in some of the next kernels?

no idea. Someone would have to file a bug report or it will never happen. If no satisfactory solution for everyone can be found, then you might get a kernel commandline parameter to force the firmware load.
Edit: Some discussions on LKML:
https://lore.kernel.org/lkml/YPNavEl340 … ycbox.lan/
https://lore.kernel.org/lkml/c0f191cc-6 … ctory.net/

Last edited by progandy (2021-07-31 15:43:35)

BollerwagenPicard · 2021-07-31 16:17:26

progandy wrote:

Has it ever worked without upd72020x-fw?

for me yes... I ordered this card new for this PC (always Linux) and would had returned it to amazon if it had not worked.

I think I'm not good enough with Linux and the English language to file a bug report for this.

But i have seen they talk about a rev2 card... mine is rev3.

progandy wrote:

It is strange that it doesn't work without firmware anymore.
Anyways as a temporary fix downgrade the kernel or try: https://github.com/markusj/upd72020x-load

this works... but i have to check how to make it automatic

Update1:
I have seen that the tool does not update the ROM of the card. But if there is an error on my card, maybe that would be a good thing to do?
https://github.com/markusj/upd72020x-lo … it#L42-L43

Update2:
I was able to solve the problem now and that too through the reboots of my device. The EEPROM was indeed damaged by the changes in the kernel.

sudo ./upd72020x-load -w -b 0x04 -d 0x00 -f 0x0 -i /lib/firmware/renesas_usb_fw.mem

With this command I was able to load the firmware from the AUR package into the ROM and the card does its job again.
If the other people affected could confirm that it helps for you too, I would like to mark it as solved.

Last edited by BollerwagenPicard (2021-07-31 16:35:16)

milan · 2021-07-31 21:28:55

BollerwagenPicard wrote:

progandy wrote:
Has it ever worked without upd72020x-fw?
for me yes... I ordered this card new for this PC (always Linux) and would had returned it to amazon if it had not worked.
I think I'm not good enough with Linux and the English language to file a bug report for this.
But i have seen they talk about a rev2 card... mine is rev3.

progandy wrote:
It is strange that it doesn't work without firmware anymore.
Anyways as a temporary fix downgrade the kernel or try: https://github.com/markusj/upd72020x-load
this works... but i have to check how to make it automatic
Update1:
I have seen that the tool does not update the ROM of the card. But if there is an error on my card, maybe that would be a good thing to do?
https://github.com/markusj/upd72020x-lo … it#L42-L43
Update2:
I was able to solve the problem now and that too through the reboots of my device. The EEPROM was indeed damaged by the changes in the kernel.
sudo ./upd72020x-load -w -b 0x04 -d 0x00 -f 0x0 -i /lib/firmware/renesas_usb_fw.mem
With this command I was able to load the firmware from the AUR package into the ROM and the card does its job again.
If the other people affected could confirm that it helps for you too, I would like to mark it as solved.

Dude, you're a lifesaver. I have completely overseen the '-w' option for upd72020x-load, instead I was using '-u' that temporarily loads the file to firmware memory. Everything works perfectly now. Cheers!

Stargatto · 2021-08-01 15:25:31

BollerwagenPicard wrote:

If the other people affected could confirm that it helps for you too, I would like to mark it as solved.

It works smoothly now! I didn't think that a kernel upgrade may damage a firmware on hw... Thank you!!!

flortsch · 2021-08-03 14:31:34

BollerwagenPicard wrote:

progandy wrote:
Has it ever worked without upd72020x-fw?
for me yes... I ordered this card new for this PC (always Linux) and would had returned it to amazon if it had not worked.
I think I'm not good enough with Linux and the English language to file a bug report for this.
But i have seen they talk about a rev2 card... mine is rev3.

progandy wrote:
It is strange that it doesn't work without firmware anymore.
Anyways as a temporary fix downgrade the kernel or try: https://github.com/markusj/upd72020x-load
this works... but i have to check how to make it automatic
Update1:
I have seen that the tool does not update the ROM of the card. But if there is an error on my card, maybe that would be a good thing to do?
https://github.com/markusj/upd72020x-lo … it#L42-L43
Update2:
I was able to solve the problem now and that too through the reboots of my device. The EEPROM was indeed damaged by the changes in the kernel.
sudo ./upd72020x-load -w -b 0x04 -d 0x00 -f 0x0 -i /lib/firmware/renesas_usb_fw.mem
With this command I was able to load the firmware from the AUR package into the ROM and the card does its job again.
If the other people affected could confirm that it helps for you too, I would like to mark it as solved.

Thinkpad T14s AMD user here, having similar issues with my webcam. Writing the firmware onto the EEPROM with your posted instructions fixed the issues. I can now use the latest kernel, even without installing the upd72020x-fw package from AUR.

Thanks a lot!

jc65536 · 2021-08-09 21:51:25

Hi BollerwagenPicard, you said that the EEPROM was damaged, does this mean a later kernel upgrade will be able to fix this automatically? I'd rather not manually edit the firmware myself, unless I absolutely have to.

BollerwagenPicard · 2021-08-10 07:41:55

hi @jc65536

this is really a very difficult question. But in my opinion, a change in the kernel module would solve the problem.
But I think this solution is rather a workaround and not a repair. By this I mean, the firmware in the EEPROM is certainly not automatically repaired by a kernel update, but the USB chip can also work with firmware from RAM. I think in a future kernel, they will try again to check the cards for a valid firmware and if this is missing, to load the card a firmware in RAM.
For you, it would mean the USB ports would work again, but the firmware on the card would still be buggy. Since the ROM firmware is usually not used when firmware is written to RAM, it should have no effect.

I hope it helps you a bit to find the right solution for you.

jc65536 · 2021-08-10 18:03:16

Thank you for the reply. I learned a bit more about the situation reading this blog post. I think I'll wait this one out, and in the meantime there are other solutions like using DroidCam, which has better picture quality than my webcam anyways

macaw · 2021-08-21 18:52:10

I've been experiencing a bunch of USB related wonkiness on a ThinkPad T14s, the most annoying of which being regularly scheduled bluetooth failures like every 5 minutes, which were accompanied by lots of very similar USB related log message to the ones posted here ("Zeroing 64bit base registers, expecting fault" and all kinds of USB device reset messages) This has been especially frustrating since I use a bluetooth mouse, keyboard and headphones regularly.

To recover from these bluetooth dropouts I'd been reloading the `btusb` module and sometimes the `xhci_pci` module.

That'd fix things for five to ten minutes, but watching dmesg showed all kinds of USB resetting and readdressing havoc happening in the background, until the bluetooth controller would stop working again.

For a while I thought it was from a bad GaN USB PD charger, but now I'm thinking it might have been this firmware issue.

I just tried rewriting the Renesas controller firmware using:

sudo ./upd72020x-load -w -b 0x05 -d 0x00 -f 0x0 -i /lib/firmware/renesas_usb_fw.mem

(noting that on my computer, the Renasas device is at bus 5, not bus 4)

The first time I got a scary error:

STATUS: confirming EEPROM write
ERROR: Writing firmware did not suceed, status register value: ba9c8020 ======> FAILED

But I tried again and got:

STATUS: confirming EEPROM write
 ======> PASSED

After successfully uploading the firmware I did:

# rmmod xhci_pci; modprobe xhci_pci

Lo and behold, the constant USB reset messages have stopped! I also plugged in a USB 3 hub and all the connected devices powered up and worked. I'm cautiously optimistic that this has fixed my bluetooth problem too. I'll report back soon to confirm or deny this.

jc65536 · 2021-09-15 02:57:24

It appears that in kernel version 5.14.3 Renesas USB3 is working again. At least, my integrated camera is working again.

Arch Linux

#1 2021-07-30 10:08:10

[Solved] USB3 stopped working with 5.13.6-arch1-1 again

#2 2021-07-30 10:26:47

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#3 2021-07-30 10:31:27

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#4 2021-07-30 11:56:25

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#5 2021-07-30 12:10:20

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#6 2021-07-30 12:29:45

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#7 2021-07-30 12:37:51

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#8 2021-07-30 15:15:11

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#9 2021-07-31 05:39:46

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#10 2021-07-31 06:23:04

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#11 2021-07-31 13:51:52

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#12 2021-07-31 15:15:05

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#13 2021-07-31 15:31:28

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#14 2021-07-31 16:17:26

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#15 2021-07-31 21:28:55

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#16 2021-08-01 15:25:31

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#17 2021-08-03 14:31:34

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#18 2021-08-09 21:51:25

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#19 2021-08-10 07:41:55

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#20 2021-08-10 18:03:16

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#21 2021-08-21 18:52:10

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

#22 2021-09-15 02:57:24

Re: [Solved] USB3 stopped working with 5.13.6-arch1-1 again

Board footer