USB controllers break when resuming from sleep mode

General system Kernel, boot, graphics & hardware
1

Hey. I’ve been kinda struggling to figure out some strange issues, can I ask for some advice?

Symptoms: When my PC goes to sleep from the timer (S3), the USB controllers that are soldered to the motherboard malfunction, and input devices do not function. When I boot back up, it only responds to USB hardware plugged into the case instead. Unplugging and plugging back in do not have any effect.

Investigation:
dmesg
I ran sudo dmesg right after it happened, the line kernel: xhci_hcd 0000:05:00.2: xHC error in resume, USBSTS 0x401, Reinit seems relevant.
Context:

... 
kernel: ACPI: PM: Restoring platform NVS memory
kernel: Enabling non-boot CPUs ...
kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2
kernel: ACPI: \_PR_.C002: Found 2 idle states
kernel: CPU1 is up
...
// Each CPU core waking up, yadda yadda yadda
...
kernel: CPU11 is up
kernel: ACPI: PM: Waking up from system sleep state S3
kernel: xhci_hcd 0000:01:00.0: xHC error in resume, USBSTS 0x401, Reinit
kernel: usb usb1: root hub lost power or was reset
kernel: usb usb2: root hub lost power or was reset
kernel: serial 00:04: activated
kernel: xhci_hcd 0000:05:00.2: xHC error in resume, USBSTS 0x401, Reinit
kernel: usb usb3: root hub lost power or was reset
kernel: usb usb4: root hub lost power or was reset
kernel: ata9: SATA link down (SStatus 0 SControl 300)
kernel: usb 1-5: reset full-speed USB device number 3 using xhci_hcd
kernel: ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)...

The whole dmesg log

udevadm
Then I looked up those number codes before the xHC errors in udevadm info --tree, and I think those two things are my USB controllers?
udevadm info --tree

A friend I was talking to about this suggested looking at two particular devices:
udevadm info -ap /sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-2/1-2:1.2/0003:046D:C52B.0003/0003:046D:406D.000B/input/input21
And udevadm info -ap /sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-2/1-2:1.2/0003:046D:C52B.0003/0003:046D:4004.0010/input/input28

udevadm info -ap on the two faulty devices:
First one
Second one

What next?
So… I’ve narrowed it down to what devices broke, but what do I do about it? Arch Wiki says something about disabling Autosuspend on certain USB devices, but this is the USB controller, it’s a PCI component actually. Can I disable autosuspend on these too?
Arch Wiki > Power Management > USB Autosuspend

Someone did recommend trying a different kernel. I tested it with main branch, LTS, and Zen. No impact.

2

What is your hardware? Post the url

inxi -Faz | eos-sendlog

3

Sorry about the delay. Here.
https://0x0.st/XaH5.txt
// About the multiple drives, only the SSD is being used. I’ve considered trying out BCacheFS and using the other drives, but for now the HDDs are just empty.

4

Have you tried usb auto suspend setting to off?

Edit: Also i see you are using lts kernel. Have you tried with the latest current kernel?

5

RE: autosuspend, I haven’t exactly tried that. Do you mean the instructions from the wiki? If so, I understood them but I’m not sure what device to attribute the settings to.
The device that’s crashing is the USB controller, which is a PCI component. So the faulty device is the controller, right? Or, I hadn’t thought of this until now, but, maybe it is the keyboard? Maybe the keyboard malfunctioning on suspend/resume is why the controller is crashing?

RE: Kernel. Five days ago I tried it with core/linux, core/linux-lts, and extra/linux-zen. I just noticed there was a more recent patch though, I’ll reboot and try again. BRB

6

You could try the following kernel parameter to disable autosuspend. I’m assuming it will be for all devices usb. If you are using systemd-boot then you have to add it in the kernel command line and re-install kernels.

How to modify kernel options:

https://discovery.endeavouros.com/installation/systemd-boot/2022/12/

autosuspend = -1

If you are using grub then you add it to the grub command line and then run the update grub command.

Edit: Not sure it will work but worth trying. I would suggest updating the Bios but i see that you have Ryzen 2600 and the bios is at 3.90. Asrocks bios updates are weird as they say not to update if using Pinnacle. Not sure what the issue is there. Most motherboard bios updates are backward compatible and of all the boards i have ever used i have not run across this.

:man_shrugging:

7

Re: BIOS updates, yeah, that really is strange, isn’t it? But even weirder, they started warning not to update while using a Pinnacle Ridge processor before the version I’m using. I tried asking their tech support what’s going on with that, and they never wrote back.

Anyway. Kernel stuff. I’m using SystemD-boot, I’ll try the kernel parameters in a minute. Thanks.
Sorry for the wait, but this glitch is hard to reproduce, for some reason it only happens when I leave it alone long enough for it to sleep, and not when I actually hit the sleep button. The best I could do is speed up the timer.

8

… Apparently they fixed this just yesterday. I was up to date when I took these notes five days ago, downloaded updates again today, and it’s fixed on core/linux 6.9.7.arch1-1.
… either that, or I’m chasing ghosts.

9

How do you know?

Edit: USB Ghosts? :laughing:

10

How do I know they fixed it yesterday? Well, the bug was happening before I updated, and now that I updated, it’s not happening.
And again, I ran updates the same day I took those notes in the opening post here. Part of trying out if the LTS kernel fixed it or not, also tested it in main-branch kernel and Zen kernel.

I’ll update if this happens again. It’s so weird, last time this happened someone suggested some settings changes for the Nvidia drivers, and it worked - for a week. This post was about that. At the time I had no clue it was about the USB ports.

11

You can tell this fast? I thought you said it took a while? :wink:

12

Well, I updated then tested it. I did change the sleep timer to one minute, too.
… Maybe I need to let it sit idle for like an hour or something before trying again.
man I hate how hard it is to repro this bug.

13

Where do you set the timer? You mean for sleep in desktop settings?

14

KDE Plasma settings > Power Management > Suspend Session: After a period of inactivity: [sleep] after [1 minute].

… Is there a command to manually and specifically put it into power state S3 sleep?

15

Not sure … but hopefully you test it for longer period and it’s good now!

16

Seems to be working. I guess it really was a kernel glitch that got patched. I’ll update if something happens again.

Thanks again

1 Like
17

Okay, this is driving me insane. It happened again. So the kernel update did not fix it after all.

And the glitch didn’t trigger until I left the machine idle for two hours. And messing with the sleep timer did not speed it up.

18

Did you try the kernel parameter as i suggested?

19

Trying it. When I get to reinstall-kernels, it seems to be working, but I see this error message a few times:
dracut[E]: Module 'systemd-pcrphase' depends on 'tpm2-tss', which can't be installed
Strange, I do have tpm2-tss installed…

But, it finished and didn’t say it failed…

edit: If that should’ve been enough, it’s not working.

20

Check the motherboard UEFI settings for the following under power management sleep or what ever category it might be under to see if it disabled for wakeup.

USB S3 Wake-up        [Disable]