Hi all, I would like to share an important update based on further testing.
After implementing a temporary workaround, I noticed that the issue is not limited to suspend/resume. There is a second trigger that seems to affect the same underlying problem. 🔍 Additional trigger identified (DPMS / screen off) Sequence: 1. System resumes from suspend → works correctly (login screen appears) 2. System becomes idle → screen turns off (DPMS) 3. Upon user interaction (keyboard/mouse), the display fails to wake properly Observed behavior: - Black screen or no signal - System remains responsive (can sometimes type blindly) - In some cases, session becomes partially corrupted Important detail: This behavior is very similar to what happens after suspend/resume: - HDMI link is not properly restored - Monitor may be misdetected or not reinitialized correctly ------------------------------ 🧪 Workaround behavior - Disabling the phantom output (DVI-D-1) restores the display immediately - Forcing HDMI-A-0 as primary also helps reinitialize the session - Disabling automatic screen-off (DPMS) avoids the issue entirely ------------------------------ 🧠 Interpretation This suggests the problem is not strictly related to suspend, but more generally to *display reinitialization after power state transitions*, including: - suspend/resume (deep) - screen power off/on (DPMS) Given that both paths trigger similar failures, this may point to issues in: - EDID re-read after power events - HDMI link training - atomic modeset state reconstruction - DC state restore ------------------------------ 💡 Conclusion The bisected commit may still represent a valid trigger point, but the root cause appears to be related to how display state is restored after power transitions, rather than suspend alone. ------------------------------ 📎 Additional notes - Wayland still does not show the same hard failure - Issue remains reproducible - Workarounds are consistent ------------------------------ I hope this additional information helps narrow down the issue further. Please let me know if I can assist with more testing. Thanks again for your time and your work. Best regards, Danilo Em dom., 29 de mar. de 2026 às 13:34, Danilo Machado < [email protected]> escreveu: > Hi all, > > I’d like to provide a final update on this regression affecting AMD Radeon > R9 380 (Tonga), which I bisected earlier between Linux 6.3 (good) and 6.4 > (bad). > > After further investigation, I was able to isolate the issue more > precisely and identify a reliable workaround. > > 🔍 Summary: > > After suspend/resume under X11: > > - > > HDMI monitor is physically connected and EDID is valid > - > > Kernel (DRM) correctly detects the HDMI connector > - > > However, X11 ends up with an inconsistent display state > > Observed behavior: > > - > > HDMI-A-0 is active at correct resolution (1920x1080) > - > > A phantom output (DVI-D-1) appears as connected > - > > DVI-D-1 is incorrectly set as primary at 640x480 > - > > Desktop becomes corrupted (missing panels, apps failing, incorrect > layout) > > xrandr example after resume: > > HDMI-A-0 connected 1920x1080+0+0 > DVI-D-1 connected primary 640x480+1920+116 > > 🧠 Key finding: > > The issue is not EDID or link training. EDID is readable and valid. > > This appears to be a failure in atomic modeset / connector-to-CRTC mapping > during resume, leading to an incorrect fallback output being selected as > primary. > > 💡 Workaround (100% reproducible fix): > > Running the following immediately restores the system: > > xrandr --output DVI-D-1 --off > xrandr --output HDMI-A-0 --primary --mode 1920x1080 > > This strongly suggests that the correct state exists but is not applied > automatically after resume. > > ⚙️ Additional observations: > > - > > Wayland does not exhibit the same failure (likely due to dynamic state > handling) > - > > Issue reproducible only on 6.4+ > - > > s2idle reduces severity but does not fix the issue > - > > amdgpu.dc=0 makes the system fully unusable after resume > > 🧪 Bisect: > > First bad commit: > b3c98052d46948a8d65d2778c7f306ff38366aac (KVM merge) > > This likely indicates an indirect trigger (timing/order change during > resume), not a direct amdgpu change. > > 📎 Logs and details available upon request. > > 🙏 I’m happy to test patches or provide additional debug information. > > Thanks for your time and for maintaining amdgpu. > > Best regards, > Danilo > > Em dom., 29 de mar. de 2026 às 10:35, Danilo Machado < > [email protected]> escreveu: > >> Also reported on GitLab: >> https://gitlab.freedesktop.org/drm/amd/-/work_items/5123 >> >> Em dom., 29 de mar. de 2026 às 09:47, Danilo Machado < >> [email protected]> escreveu: >> >>> Additional testing: >>> >>> I tested with amdgpu.dc=0 to disable Display Core. >>> >>> Result: >>> - system becomes completely unresponsive after resume >>> - black screen, no input response >>> >>> This suggests the issue is not limited to Display Core (DC), >>> but likely affects the core GPU resume path. >>> >>> With DC enabled: >>> - partial recovery (corrupted display, EDID failure) >>> >>> With DC disabled: >>> - complete failure >>> >>> This reinforces that the regression is deeper in the amdgpu resume >>> sequence. >>> >>> Em sex., 27 de mar. de 2026 às 21:14, Danilo Machado < >>> [email protected]> escreveu: >>> >>>> 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. >>>> >>>> >>> >>> -- >>> *Danilo Machado* >>> >> >> >> -- >> *Danilo Machado* >> > > > -- > *Danilo Machado* > -- *Danilo Machado*
