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

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 2910 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 13449 bytes --]

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 5338 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 28561 bytes --]

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 5431 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 29755 bytes --]

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 6453 bytes --]

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*

[-- Attachment #2: Type: text/html, Size: 26889 bytes --]

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 6963 bytes --]

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*

[-- Attachment #2: Type: text/html, Size: 27821 bytes --]

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 9606 bytes --]

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*

[-- Attachment #2: Type: text/html, Size: 27702 bytes --]

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

[Danilo Machado]

[-- Attachment #1: Type: text/plain, Size: 12671 bytes --]

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.
🔍 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*
>


-- 
*Danilo Machado*

[-- Attachment #2: Type: text/html, Size: 30949 bytes --]

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

[Timur Kristóf]

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*