Re: [REGRESSION][bisected] amdgpu/tonga: HDMI no signal after suspend/resume

["Timur Kristóf" <timur.kristof@gmail.com>]

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 <
> 
> danilomachado2002@gmail.com> 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 <
> > 
> > danilomachado2002@gmail.com> 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 <
> >> 
> >> danilomachado2002@gmail.com> 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 <
> >>> 
> >>> danilomachado2002@gmail.com> 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 <danilomachado2002@hotmail.com>
> >>>> *Enviado:* quinta-feira, 26 de março de 2026 20:38
> >>>> *Para:* amd-gfx@lists.freedesktop.org <amd-gfx@lists.freedesktop.org>
> >>>> *Cc:* Alex Deucher <alexdeucher@gmail.com>;
> >>>> dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>
> >>>> *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*