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*
