Additional data (resume failure analysis)
Hardware:
- GPU: AMD Radeon R9 380 (Tonga, GCN 3)
- CPU: AMD Ryzen 5 5500
- RAM: 16 GB
- Display: HDMI
Software:
- Kernel: 6.8.0-106-generic
- Driver: amdgpu
- Display server: X11 (issue reproducible), Wayland (no hard failure)
---
Summary:
After suspend/resume, HDMI output is not restored and the system may freeze
under X11.
The issue is reproducible and was not present in Linux 6.3.
---
Key observation:
During resume, the driver fails to read EDID:
amdgpu 0000:01:00.0: [drm] *ERROR* No EDID read.
This appears to explain why HDMI output is not restored.
---
Relevant DRM / AMDGPU log excerpt:
[drm] Display Core v3.2.266 initialized on DCE 10.0
amdgpu 0000:01:00.0: [drm] *ERROR* No EDID read.
[drm] Initialized amdgpu 3.57.0 20150101 for 0000:01:00.0
---
Analysis:
- The failure occurs during display reinitialization after resume
- EDID read failure prevents proper HDMI modeset
- This aligns with the observed "no signal" condition
Behavior differences:
- deep sleep:
- full GPU/display reinitialization
- leads to EDID failure and system instability
- s2idle:
- partial resume
- avoids full lockup but display may still be inconsistent
This suggests the issue is in the display resume path, possibly involving:
- DC state restore
- HDMI link training
- DDC/EDID communication
- atomic modeset reconstruction
---
Conclusion:
This is likely a regression in the AMDGPU display resume path, where EDID
read fails after resume, preventing HDMI output from being restored.
---
Additional notes:
This issue was bisected between Linux 6.3 (good) and 6.4 (bad), with the
transition point identified as a KVM merge commit. While not directly
related to AMDGPU, it may have indirectly exposed this issue via
timing/order changes.
---
If needed, I can provide:
- full journalctl logs
- full bisect log
- additional testing (kernel params, debug options)
------------------------------
*De:* Danilo Machado <[email protected]>
*Enviado:* quinta-feira, 26 de março de 2026 20:38
*Para:* [email protected] <[email protected]>
*Cc:* Alex Deucher <[email protected]>; [email protected]
<[email protected]>
*Assunto:* [REGRESSION][bisected] amdgpu/tonga: HDMI no signal after
suspend/resume
Hi all,
Thanks again for your feedback.
I took a closer look at the bisect results and system behavior, and I’d
like to provide a more complete and consolidated report.
------------------------------
Hardware:
-
GPU: AMD Radeon R9 380 (Tonga, GCN 3)
-
CPU: AMD Ryzen 5 5500
-
RAM: 16 GB
-
Display: HDMI
Software:
-
Driver: amdgpu
-
Kernel range tested: 6.3 (good) → 6.4 (bad)
------------------------------
Summary:
This is a reproducible suspend/resume regression affecting HDMI output.
-
Linux 6.3 → working correctly
-
Linux 6.4+ → regression present
------------------------------
Behavior:
After suspend/resume:
-
HDMI output does not recover ("no signal")
-
System may freeze under X11
-
Wayland does not show the same hard failure
Additionally:
-
Using "deep" sleep:
-
full system lockup after resume
-
Using "s2idle":
-
system resumes without hard lock
-
however, graphical session may return in a partially broken state
------------------------------
Bisect result:
A full git bisect was performed between Linux 6.3 and 6.4.
First bad commit:
b3c98052d46948a8d65d2778c7f306ff38366aac
("Merge tag 'kvm-x86-vmx-6.4'")
All intermediate commits in that range were consistently tested as GOOD.
------------------------------
Analysis:
Although the bisected commit is in KVM and unlikely to directly affect
AMDGPU, the transition point is consistent and reproducible.
This suggests the regression may be indirectly triggered (e.g. timing or
ordering changes during resume), rather than caused directly by that merge.
Based on observed behavior, this appears related to the display resume
path, possibly involving:
-
DC state restore after resume
-
HDMI link training
-
EDID re-read
-
atomic modeset state reconstruction
The difference between "deep" and "s2idle" also suggests a failure during
full GPU/display reinitialization.
------------------------------
Conclusion:
This appears to be a latent issue exposed by changes introduced during the
6.4 merge window, rather than a direct regression in the bisected commit
itself.
------------------------------
If helpful, I can assist further by:
-
providing full bisect logs
-
capturing detailed dmesg/journalctl before and after resume
-
testing patches or debug options
-
narrowing the range further if needed
I really appreciate the work on AMDGPU and would be glad to help within my
limits to investigate this further.
Thanks again for your time.
Best regards,
Danilo
Note: I had some email client configuration issues earlier, which may have
caused duplicate messages or formatting problems. These have now been
resolved — apologies for any inconvenience.
