https://bugzilla.suse.com/show_bug.cgi?id=1206758 https://bugzilla.suse.com/show_bug.cgi?id=1206758#c12 Oliver Neukum <oneukum@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #12 from Oliver Neukum <oneukum@suse.com> --- (In reply to Pablo Sanchez from comment #10)

(In reply to Oliver Neukum from comment #8)

...

The failure you are seeing is on the PCI level. From your logs it is unclear whether the HC that fails to resume is hosting other busses. It is possible that it is just not resumed without a device.

Hi,

My work-around is to resume, *then* connect the device.

Sorry, this probably needs a long explanation. From usbcore's viewpoint your roothub on the XHCI without any device connected to it will be in the state (suspended w. remote wakeup) after your system resumes that is the desired state of the root hub, too. So without devices if your system is suspended, no PM transitions will be done on the roothub. If, however, your system is connected to your phone, the roothub and the phone need to be in (active) before and after the system sleeps. So PM transitions are certainly done. My theory was that your system is generally incapable of a PM transition on the PCI level at that time. If that theory were true, your system should crash with any device that is in (active) attached and it should also crash if you artificially force the roothub into a PM transition on resume, which was my second suggestion.

...

Do you have other devices to test to make sure it is not specific to your phone?

What an excellent idea. As my phone is a Samsung S21, non-root, I hadn't thought it might be an issue.

Using another phone (OnePlus Nord), it works.

Please attach the output of "lsusb -v" in the working state with that second phone connected.

...

Alternatively, if not, it would be necessary to set the "control" attribute for your root hub to "on".

I think you're saying a work-around is for me to create a udev rule.

No, that was for testing purposes only. Something is failing on the PCI level. You cannot fix that with a udev rule. So please test whether the fault is related to ASPM by doing Takashi's test. From your log: [26232.379255] xhci_hcd 0000:a4:00.0: Unable to change power state from D3cold to D0, device inaccessible [26232.457787] xhci_hcd 0000:a4:00.0: Unable to change power state from D3cold to D0, device inaccessible These must not happen. If they do, everything after that is as expected, though not as desired. Unfortunately everything before them is as it should be. Hence tests to determine the cause of this issue are needed. -- You are receiving this mail because: You are on the CC list for the bug.