Are there any chances to track down what causes the issue exactly?
(Background: If it is number 1 then I return the “front panel USB Hub”. If it is number 2 or 3 then I have to wait for a kernel update or a new BIOS version.)
I’ll go out on a limb here…the answer is number 1, but the hub is not defective.
Here’s why I think that:
It’s got charging ports. Most people (if they actually hook their device to a computer to charge) would not want the computer to go to sleep while charging. Perhaps the hub’s comtroller could’ve been programmed better (only keep awake when something is connected to a charging port).
I summarize:
Execute cat /proc/acpi/wakeup
If here you see xhci_hcd you can disable its wakeups: # echo *device-name* > /proc/acpi/wakeup
(root can write here)
But this will not persist across reboots, so you’ll have to make a systemd unit, like, eg, /etc/systemd/system/xhci_hcd-disable-wakeups.service with the following content:
So, I disabled xhci1 with this command (as root): echo XHC1 > /proc/acpi/wakeup
The next suspend did not work. There was another device refusing to go to sleep: xhci_hcd 0000:0a:00.3: refused to change power state from D0 to D3hot
(The former device was: xhci_hcd 0000:0a:00.**4**)
So I did a reboot and disabled both devices with: echo XHC1 > /proc/acpi/wakeup echo XHC0 > /proc/acpi/wakeup
After this cat /proc/acpi/wakeup resulted in this:
Device
S-state
Status Sysfs node
GPP6
S4
*disabled
GP17
S4
*enabled pci:0000:00:08.1
XHC0
S4
*disabled pci:0000:0a:00.3
XHC1
S4
*disabled pci:0000:0a:00.4
PS2K
S3
*disabled
GPP0
S4
*disabled
GPP5
S4
*disabled
GPP3
S4
*enabled pci:0000:00:02.1
But the next suspend did not work either. The same device refused to go to sleep: xhci_hcd 0000:0a:00.3: refused to change power state from D0 to D3hot
(lspci says that for that device: 0a:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir USB 3.1
To that port I connected the USB ports of my case (Cooler Master Silencio S600)).
Few months back, I developed a problem like this. Turned out that a capacitor on the little controller card for the keyboard had developed a short. Replaced keyboard ($DEITY, I lament the demise of Radio Shack), no probs since.
Such command, as I stated, is not for disabling the device, but for inhibit the wakeups from such device.
But there is a way to disable instead USB devices from commandline: by installing and using usb_modeswitch (is available in the official repo).
Is utilizable in such way: usb_modeswitch -v $VendorID -p ProductID -Q
You can get VendorID and ProductID by checking the output of lsusb (I assume that could be an USB hub due xhci_hcd)
But be aware: there is the possibility that after resume, the device could remains in the “disabled” state. (you can also try by insert -d before -Q)
I have used usb_modeswitch in past (I had a pair of USB wlan adapters which caused me issues on suspend and on resume); one of them reactivate itself on resume, the other one needed to be detached and reattached from the USB port.
At least, we should to determine if is a software or hardware related issue:
When it started to occurs? Since the first day you own this computer? Or you also updated the BIOS once? It occurs also with other operating systems? Did you tried to boot a live iso (Manjaro or other OS), eg burned to an usb stick? Did you tried to boot with another kernel?
I do not exactly know when this behavior started to occur. Due to the system journal it was between 2020-12-15 and 2020-12-21.
In this period I attached the “front panel USB hub” and I also updated BIOS to the new version.
This new BIOS version I updated (F11p) you cannot download anymore. Usually that means, that a new version will be published soon. I will wait for this version and then I tell you if it fixed the problem.
And one more thing (to make the hole issue more confusing ):
Earlier I stated that this message causes the trouble:
But now I am not sure anymore, because I searched the system journal for entries when suspend worked for me… And there I saw the following entry:
But not before suspend. This message came right after wake up (and at this time suspend worked).
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.1 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 008: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
Bus 001 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 005: ID 048d:5702 Integrated Technology Express, Inc. ITE Device
Bus 001 Device 006: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 004: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Because I could not say which device belongs to my “front panel USB hub”, I disconnected it and then lsusb show this:
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 003: ID 048d:5702 Integrated Technology Express, Inc. ITE Device
Bus 001 Device 004: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
So I think that these entries belong to the “front panel USB hub”:
Bus 002 Device 002: ID 05e3:0625 Genesys Logic, Inc. USB3.1 Hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
So, since you don’t know which device belongs to your “front panel USB hub”, (VendorID and ProductID) usb_modeswitch didn’t worked at all as expected, or at least how we hoped. Which parameters did you gave to usb_modeswitch? It needs VendorID and ProductID, to disable the device, as I said above:
I did this (without -Q to get some messages): sudo usb_modeswitch -v 05e3 -p 0625 -d
This resulted in this:
` Look for default devices ...`
` Found devices in default mode (1)`
`Access device 002 on bus 002`
` Get the current device configuration ...`
`Current configuration number is 1`
` Use interface number 0`
`with class 9`
`Detach storage driver as switching method ...`
`Looking for active drivers ...`
` OK, driver detached`
`-> Run lsusb to note any changes. Bye!`
The following suspend did not work. `journalctl --system --boot` shows this:
`Jan 06 17:49:07 manjaro systemd[1]: Reached target Sleep.`
`Jan 06 17:49:07 manjaro systemd[1]: Starting Suspend...`
`Jan 06 17:49:08 manjaro systemd-sleep[4144]: Suspending system...`
`Jan 06 17:49:08 manjaro kernel: PM: suspend entry (deep)`
**Jan 06 17:49:08 manjaro kernel: Filesystems sync: 0.001 seconds**
**Jan 06 17:49:14 manjaro kernel: Freezing user space processes ... (elapsed 0.002 seconds) done.**
` Jan 06 17:49:14 manjaro kernel: OOM killer disabled.`
` Jan 06 17:49:14 manjaro kernel: Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.`
`Jan 06 17:49:14 manjaro kernel: printk: Suspending console(s) (use no_console_suspend to debug)`
` Jan 06 17:49:14 manjaro kernel: [drm] free PSP TMR buffer`
`Jan 06 17:49:14 manjaro kernel: xhci_hcd 0000:0a:00.3: refused to change power state from D0 to D3hot`
`Jan 06 17:49:14 manjaro kernel: ACPI: Preparing to enter system sleep state S3`
`Jan 06 17:49:14 manjaro kernel: PM: Saving platform NVS memory`
`Jan 06 17:49:14 manjaro kernel: Disabling non-boot CPUs ...`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 1 is now offline`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 2 is now offline`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 3 is now offline`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 4 is now offline`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 5 is now offline`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 6 is now offline`
` Jan 06 17:49:14 manjaro kernel: smpboot: CPU 7 is now offline`
` Jan 06 17:49:14 manjaro kernel: smpboot: CPU 8 is now offline`
`Jan 06 17:49:14 manjaro kernel: smpboot: CPU 9 is now offline`
` Jan 06 17:49:14 manjaro kernel: smpboot: CPU 10 is now offline`
` Jan 06 17:49:14 manjaro kernel: smpboot: CPU 11 is now offline`
`Jan 06 17:49:14 manjaro kernel: ACPI: Low-level resume complete`
` Jan 06 17:49:14 manjaro kernel: PM: Restoring platform NVS memory`
` Jan 06 17:49:14 manjaro kernel: LVT offset 0 assigned for vector 0x400`
` Jan 06 17:49:14 manjaro kernel: Enabling non-boot CPUs ...`
` Jan 06 17:49:14 manjaro kernel: x86: Booting SMP configuration:`
`Jan 06 17:49:14 manjaro kernel: smpboot: Booting Node 0 Processor 1 APIC 0x2`
` Jan 06 17:49:14 manjaro kernel: microcode: CPU1: patch_level=0x08600106`
`Jan 06 17:49:14 manjaro kernel: ACPI: \_SB_.PLTF.C002: Found 3 idle states`
`Jan 06 17:49:14 manjaro kernel: CPU1 is up`
` ...`
There are six seconds with no messages (I tried to make them bold). And that is always true for every failed suspend. What does that mean? Does suspend work for me for six seconds? Or are there any messages missing?
And I installed a new BIOS (version F11 from 2020-12-31) but with no luck.
