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*
