Am 29.05.25 um 09:17 schrieb Rainer Fiebig:
Am 28.05.25 um 23:09 schrieb Deucher, Alexander:
[Public]
-----Original Message----- From: Rainer Fiebig jrf@mailbox.org Sent: Friday, May 23, 2025 3:54 PM To: stable@vger.kernel.org; Deucher, Alexander Alexander.Deucher@amd.com Subject: 6.12.30: black screen after waking up from hibernate; bisected
With kernel 6.12.30 waking up from hibernate fails in a Ryzen 3 5600G system with the latest BIOS. At the end of the wake-up procedure the screen goes black instead of showing the log-in screen and the system becomes unresponsive. A hard reset is necessary.
Seeing messages like the following in the system log, I suspected an amdgpu problem:
May 23 19:09:30 LUX kernel: [16885.524496] amdgpu 0000:30:00.0: [drm] *ERROR* flip_done timed out May 23 19:09:30 LUX kernel: [16885.524501] amdgpu 0000:30:00.0: [drm] *ERROR* [CRTC:73:crtc-0] commit wait timed out
I don't know whether those messages and the problem are really related but I bisected in 'drivers/gpu/drm/amd' anyway and the result was:
git bisect bad
25e07c8403f4daad35cffc18d96e32a80a2a3222 is the first bad commit commit 25e07c8403f4daad35cffc18d96e32a80a2a3222 (HEAD) Author: Alex Deucher alexander.deucher@amd.com Date: Thu May 1 13:46:46 2025 -0400
drm/amdgpu: fix pm notifier handling commit 4aaffc85751da5722e858e4333e8cf0aa4b6c78f upstream. Set the s3/s0ix and s4 flags in the pm notifier so that we can skip the resource evictions properly in pm prepare based on whether we are suspending or hibernating. Drop the eviction as processes are not frozen at this time, we we can end up getting stuck trying to evict VRAM while applications continue to submit work which causes the buffers to get pulled back into VRAM.HTH. Thanks.
Fixed in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... and on it's way to stable.
Great, thanks! I had already reverted your commit in an experimental branch and that solved the problem - so either your commit was bad or something that it somehow depended on.
The problem that now reverted commit 68bfdc8dc0a1a tried to solve is indeed irritating/confusing and hopefully you'll find an other way to solve it. The whole procedure is suboptimal insofar as there is no feedback as to what is going on and whether the process has finally concluded and it is safe to switch off the box.
My - perhaps naive - suggestion would be to provide at least some feedback by leaving the monitor _on_ until the image has been written to disk and the box can be switched off.
To clarify a bit what I mean: if possible, the display should stay "on" _all the while_ from initiating hibernate until the image has been written to disk and shutdown is complete, so that the user can tell from the status of the monitor's power-LED whether it's safe to switch the computer off. Neither an "off-on, off-on..." nor an "off" during that phase is helpful.
Rainer