Comment 134 for bug 2034477

(In reply to Mario Limonciello (AMD) from comment #52)

I finally managed to test the v2 patch (from comment #51). The keyboard and touchpad work fine.

> Also, I notice in your log you tested hibernate (suspend to disk), not
> suspend-to-ram.
>
> > [ 0.355620] Low-power S0 idle used by default for system suspend
>
> Can you please test suspend to idle (the default for your system).

I was imprecise with my choice of words: what I had tested was `systemctl hybrid-sleep`, which I assumed was equivalent to suspend-to-ram unless the battery runs empty while suspended. That appears not to be the case, so this time I tested all three:

1. systemctl hibernate -- "suspend to disk", this seems to work fine.

2. systemctl hybrid-sleep -- also seems to work fine

3. systemctl suspend -- "suspend to ram", had some issues: the first attempt managed to suspend, but upon resume the file system was reporting IO errors, to the point that even "ls" didn't work anymore. I couldn't get a dmesg output in this state. (Interestingly enough, my ssh connection resumed fine, presumably because it was already in RAM). I tried again, this time running in background `dmesg -w > dmesg-6.6.0-rc6-v2-suspend.txt`, so I'd at least capture output up to the crash (attached). This time, resume seemed to work, so I tried again, and this third time, the network did not resume properly, so I couldn't continue my ssh session, but the file system seemed to be ok, so I got some dmesg output (dmesg-6.6.0-rc6-v2-suspend-2.txt). There's a kernel stack trace in there, with this message:

> [ 804.018115] Hardware became unavailable upon resume. This could be a
> software issue prior to suspend or a hardware issue.

I'll attach the logs right away.