On Sunday, March 29, 2026 11:36:19 PM Central European Summer Time Danilo Machado wrote: > 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.
Hi Danilo, I responded on the GitLab issue. I recommend to continue the conversation there. Best regards, Timur > 🔍 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*
