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*
