Thanks again for the help, much appreciated!! I will try your suggestions but I can’t do it right now, I am in the middle of something and I can’t risk my pc to freeze. Late night or tomorrow morning I will try and tell the result. With your help I am optimistic
@dimig33 so two things (and my reason to never touch AMD carp) how are your screens connected, if HDMI switch to DP, else could be the seemingly never ending bug opened some 6 years ago…https://gitlab.freedesktop.org/drm/amd/-/issues/662#note_2731990
Solved!!! (at least for now)
I tried unsuccessfully some of the suggestions from oldcpu (thanks again for your effort to help). Then I start looking for my motherboard compatibility with the new cpu and long story sort I find the solution there https://forums.linuxmint.com/viewtopic.php?p=2524468&hilit=won't+suspend#p2524468 and there updated BIOS: system immediately resumes from suspend (Gigabyte B550) / Kernel & Hardware / Arch Linux Forums
Even after search I din’t figured out what GPPO stands for so I could disable it from bios, the conclusion is times b550 aorus elite has compatibility issues. I did’t understand why now and not in the past, also I hope some kernel update or better bios update fixes the problem. Now i can suspend from gnome, either using the suspend button or when time passed.
P.S. The two monitors connected through display port the one and through hdmi the second. Both work fine.
For future reference seems it is the least suspect that causes the problem: the second NVME disk Reddit - The heart of the internet
Congratulations.
Is you current solution functional across reboots?
If not, let us know if you need assistance in having this functional across reboots without having to do anything extra (once the permanent fix you may wish to setup is in place).
Here is what I read about GPP0:
GPP0 stands for “General Purpose PCIe Port 0” - it’s an ACPI device identifier that represents a specific PCIe root port or bridge on your computer’s AMD B550 chipset. On your specific motherboard GPPO may refer to:
- PCIe Root Port: The first general-purpose PCIe bridge/root port on the AMD B550 chipset
- NVMe Bridge: Often the bridge that connects to your primary M.2 NVMe SSD slot
- GPU Communication Path: May handle communication between CPU and discrete graphics
Which frankly, IMHO, did not help me much at first in understanding. Later on it started to make a bit of sense.
So my not understanding, I continued researching and discovered that GPP0 can cause sleep issues.
In a default state GPP0 is often enabled as a wake source by default in ACPI tables.
When it comes to ‘wake events’ I read (this that I read was possibly written by an MS-Windows’ fan ? ) that when it comes to GPPO Linux ACPI Handling, that Linux doesn’t always handle these wake events correctly, leading to the black screen issue you experienced.
Also the Port-0 in GGP0 puzzled me. Port 0? Why not GPP1 (Port 1)?
Digging further, on AMD platforms the GPP ports are numbered (GPP0, GPP1, GPP2, etc.). Each port handles different PCIe lanes and devices. GPP0 is typically the most critical as it often connects to primary storage (NVMe) or high-speed devices.
When you run echo GPP0 >> /proc/acpi/wakeup, you’re enabling GPP0’s wake capability in the Linux ACPI subsystem. Previously your keyboard/mouse wake signals were likely routed through the PCIe infrastructure that GPP0 represents, and without GPP0 enabled as a wake source, the wake signals associated with those devices couldn’t reach the system.
By enabling GPP0 as a wake source, you restored the ability for input devices (keyboard/mouse) to wake the system from sleep through the PCIe root port that GPP0 represents.
Now I may have the above a bit ‘fuzzy’ but that is how I see this at present.
I read you can check the current state with:
cat /proc/acpi/wakeup
Look for GPP0 in the list - if it shows “enabled” or has an asterisk, that’s why your wake-up now works.
Good luck here , and thank-you for sharing your solution.
Here’s what I did exactly
first i run the command
sudo /bin/bash -c "echo GPP0 >> /proc/acpi/wakeup"
This works ok, so I create a service to run the command every time I reboot
sudo nano /etc/systemd/system/wakeup-disable_GPP0.service
Then I add in this file the following
[Unit]
Description=Fix suspend by disabling GPP0 sleepstate thingie
[Service]
ExecStart=/bin/bash -c "echo GPP0 >> /proc/acpi/wakeup"
[Install]
WantedBy=multi-user.target```
Then I enable and start the service
``sudo systemctl enable wakeup-disable_GPP0.service
sudo systemctl start wakeup-disable_GPP0.service```
So every time I reboot now the service run and disables GPP0. The full list what is enabled and what disabled
mitsos@tumbleweed:~> cat /proc/acpi/wakeup
Device S-state Status Sysfs node
GP12 S4 *enabled pci:0000:00:07.1
GP13 S4 *enabled pci:0000:00:08.1
XHC0 S4 *enabled pci:0000:0a:00.3
GP30 S4 *disabled
GP31 S4 *disabled
PS2K S3 *disabled
GPP0 S4 *disabled pci:0000:00:01.1
GPP8 S4 *enabled pci:0000:00:03.1
SWUS S4 *enabled pci:0000:06:00.0
SWDS S4 *enabled pci:0000:07:00.0
PTXH S4 *enabled pci:0000:02:00.0
PT20 S4 *disabled
PT21 S4 *disabled
PT22 S4 *disabled
PT23 S4 *disabled
PT24 S4 *enabled pci:0000:03:04.0
PT26 S4 *disabled
PT27 S4 *disabled
PT28 S4 *enabled pci:0000:03:08.0
PT29 S4 *disabled
this the full list
Now the pc sleeps ok and keeps doing it after reboot.
Thanks again for your efforts and explanations
1 Like
Thanks for sharing your solution.
I confess I was surprised to read this (where I had thought the command you sent would enable GPP0):
I was expecting to read ‘enabled’ and not ‘disabled’. So maybe my understanding is not yet up to par.
Was that command sent before you ‘enabled’ the ‘service’ (that may be the incorrect name).
Neither do I understand well. 
Him who proposed the solution named it “service”
Apologies - this was puzzling me, and I struggled to let it go and accept it, until I understood this better.
I concede I initially found this very counter-intuitive.
So I dug into this some more, and learned this is very hardware specific.
Research into this suggests to me that in fact it was necessary to disable your computer’s GPP0’s ability to wake the system because GPP0 (which is typically a PCIe root port) was causing spurious wakeups that resulted in the black screen and unresponsive system issues you described.
i.e. GPP0 wakeup was deliberately disabled, to stop an issue different from what we both suspected !!
The service name “wakeup-disable_GPP0.service” , as you labelled it, is accurately named - it’s disabling GPP0’s wakeup capability. The fact that GPP0 shows as “*disabled” in their final output confirms that:
GPP0 is tuned such that it cannot wake the system from suspend !!
“GPP0=disabled” means the wakeup capability for the GPP0 device is turned OFF, which is purportedly what you needed to achieve. I never would have guessed that !!
You successfully disabled a problematic wakeup source which was causing issues. Purportedly, this is a common fix for AMD B550 chipset suspend/resume issues where certain PCIe devices cause problems when allowed to wake the system.
Further, I read GPP0 being “disabled” in /proc/acpi/wakeup doesn’t prevent ALL wakeups from working. It only prevents GPP0 specifically from waking the system.
Looking at your wakeup list, you still have many other devices that remain “enabled” and can wake the system:
GP12 (*enabled)
GP13 (*enabled)
XHC0 (*enabled) - USB controller
GPP8 (*enabled)
SWUS (*enabled)
SWDS (*enabled)
PTXH (*enabled)
PT24 (*enabled)
PT28 (*enabled)
Presumably you can still wake your system using:
- Keyboard/mouse (through XHC0 - USB controller)
- Power button
- Network activity (Wake-on-LAN)
- Other enabled PCIe devices
Hence I misunderstood the problem you encountered.
The problem you encountered, and that you eventually solved wasn’t that your system wouldn’t wake up because of a GPP0 not waking up - rather it was that GPP0 was causing unwanted/spurious wakeups that resulted in:
- Black screen issues
- System becoming unresponsive
- Essentially “broken” wake behavior
And hence by disabling GPP0’s wakeup capability, you have prevented this specific PCIe root port from triggering problematic wake events, while still allowing normal, intentional wakeups through other properly functioning devices.
So “wakeup successfully takes place” through the other enabled devices, just not through the problematic GPP0 device that was causing issues.
Go figure.
Glad you found the solution on the internet, as I was looking in entirely the WRONG direction.
Thankyou for sharing your solution.
1 Like
You spent a lot of energy to this, thats nice. Still cant figure out what GPP0 doing. when i run
mitsos@tumbleweed:~> lspci | grep 00:01.1
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge
It seems to me that is the B550 chipset pci lane that enables the second NVME, so the addition of a second disk caused the problem. Still not sure, dont find what tis “Starship/Matisse GPP Bridge” doing
Yes, I also think the second NVME uses the B550 chipset bus PCIe lane.
This is my understanding …
Reference 00:01:1, my understanding is
00 is the bus number.
01 is the device number.
1 is the function number
PCI bridge: A PCI bridge is a hardware component that connects two PCI buses, allowing communication between them. In a system like AMD’s B550, these buses are:
- The primary bus (PCIe 4.0), directly tied to the Ryzen CPU, which handles the GPU and primary NVMe SSD.
- The secondary bus (PCIe 3.0), managed by the B550 chipset, which supports additional PCIe 3.0/2.0 lanes and onboard devices (like SATA, USB, Ethernet, Wi-Fi, or a secondary NVMe SSD).
The bridge routes data between these buses and manages the system’s bus hierarchy. It’s a critical component because many devices depend on it for proper operation.
Starship/Matisse GPP Bridge: This is the name assigned to the specific model of the bridge in use. “Starship” is the codename for AMD’s B550 chipset architecture, while “Matisse” is the codename for the Zen 2-based Ryzen 3000 series CPUs. A “GPP” (General Purpose Peripheral) bridge is a generic term for a bridge that connects to various peripheral devices.
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.