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.
]]>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.
]]>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-L43Update2:
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!
]]>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!!!
]]>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-L43Update2:
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!
]]>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.
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.
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/
[ 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
Anyways as a temporary fix downgrade the kernel or try: https://github.com/markusj/upd72020x-load
]]>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
]]>[ 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