Bug 206473 - S2Ram fails resume on - x570 (Gigabyte Aorus Ultra), Ryzen 3700x
Summary: S2Ram fails resume on - x570 (Gigabyte Aorus Ultra), Ryzen 3700x
Status: RESOLVED UNREPRODUCIBLE
Alias: None
Product: ACPI
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 low
Assignee: acpi_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-09 15:12 UTC by s7mon
Modified: 2020-06-23 06:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.5.2
Subsystem:
Regression: No
Bisected commit-id:


Attachments
steps and output of steps according to basic-pm-debugging (2.41 KB, text/plain)
2020-02-09 15:12 UTC, s7mon
Details

Description s7mon 2020-02-09 15:12:48 UTC
Created attachment 287261 [details]
steps and output of steps according to basic-pm-debugging

Description:
Using a Ryzen 3700x on an Gigabyte Aorus Ultra X570 board resume fails from suspend to ram.

Details:
using pm-suspend the system successfully suspends to ram (low power consumption seen on monitoring).

Actual Result:
When issuing wake up (e.g. from Keyboard) power consumption goes up to regular load but no screen/network/disk activation.
Screen stays black. Can't ssh into the machine and a spinning disk attached for testing is not spun up.

Additional Information:
Suspend to disk works fine including resume.
Did some pm_testing as good as i understood basic-pm-debugging instructions (see suspend_testing.txt attached)
Furthermore a suspend cycle was done with pm_trace

[    1.200795] PM:   Magic number: 0:571:178
[    1.201315] PM:   hash matches drivers/base/power/main.c:1331
[    1.201874] acpi PNP0C02:0b: hash matches
[    1.202396] acpi device:0e: hash matches
[    1.202918]  platform: hash matches

I found out that PNP0c02 is for Motherboard resources but my knowledge how to investigate beyond that is limited.

Source file at 1331 is the trace call of
static int __device_suspend_noirq(struct device *dev, pm_message_t state, bool async)
..
Complete:
complete_all(&dev->power.completion);
TRACE_SUSPEND(error);
return error;
} 


I used gentoo-sources (5.4.12, 5.5.1) and plain source from kernel.org (5.5.2) same behavior.

Did some testing on a windows (10 1903) installation where i could successfully suspend/resume after installing chipset drivers.

Not sure where the root of problem is (e.g. bios quirk or sth. else) any help welcome.
Comment 1 s7mon 2020-06-23 06:40:49 UTC
Last week the board died and i could replace it with a MSI meg x570 ace. Here the suspend/resume worked on a first test (ui was still sluggish afterward - will need to investigate). 
Closing this as i can not reproduce anymore.

Note You need to log in before you can comment on or make changes to this bug.