Hi,

Upgrading (after a long while) Debian Trixie installations on two
different HP EliteDesk 705 G4 DM 35W computers with AMD PRO A10-9700E R7
(carrizo) resulted in both machines blanking the screen right after
kernel modesetting activates via amdgpu, with the monitor reporting "no
signal". There are no other symptoms besides losing the display as the
system continues to run and is accessible using keyboard and network.

Bug first discovered with stable kernel
linux-image-6.12.90+deb13.1-amd64 (6.12.90-2) and the one from
trixie-backports. The device is connected to a monitor using a
DisplayPort to HDMI adapter. The bug occurs regardless of which if the
two available physical DisplayPort ports to use.

I don't remember this being an issue some months ago, so I tried to
reproduce this booting the Debian 13.1.0 and 13.4.0 install DVD images
and using the kernel modules/firmware therein:

   13.1.0 installer:
     firmware-amd-graphics_20250410-2
     linux-image-6.12.43+deb13-amd64_6.12.43-1
   13.4.0 installer:
     firmware-amd-graphics 20250410-2
     linux-image-6.12.73+deb13-amd64_6.12.73-1

I essentially unpacked the two *.deb files manually, depmod -a; modprobe
drm debug=0x1ff; modprobe amdgpu.

I observed the bug reproduce using the 13.4.0 installer, but not on the
13.1.0 installer, meaning this is a regression somewhere between kernel
versions 6.12.43-1 and 6.12.73-1.

Best regard,
Jaak

Using kernels from snapshot.debian.org, I narrowed this down even further:

Not affected:
  * linux-image-6.12.48+deb13-amd64_6.12.48-1_amd64.deb
  * linux-image-6.12.57+deb13-amd64_6.12.57-1_amd64.deb
  * linux-image-6.12.63+deb13-amd64_6.12.63-1_amd64.deb

Affected:
  * linux-image-6.12.69+deb13-amd64_6.12.69-1_amd64.deb

Hi,

This is already great so we have a closer range. Can you please bisect
the changes between 6.12.63 and 6.12.69 upstream to identify the
offending commit introducing the problem?  Here is a small procedure:

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.63
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.63 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem does not exist

    # test 6.12.69 to ensure this is "bad"
    git checkout v6.12.69
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm problem exists

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v6.12.63
    git bisect bad v6.12.69

In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:

    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install, verify if problem exists

and if the problem is hit run:

    git bisect bad

and if the problem doesn't trigger run:

    git bisect good

. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.

Iterate until git announces to have identified the first bad commit.

Then provide the output of

    git bisect log

In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.

Regards,
Salvatore

I already managed to bisect the kernel using much more crude means, as I
was not aware of these nice tricks - thanks! :)

Here is the bisect log I got:

git bisect start
# status: waiting for both good and bad commits
# bad: [ff2177382799753070b71747f646963147eabc7c] Linux 6.12.69
git bisect bad ff2177382799753070b71747f646963147eabc7c
# status: waiting for good commit(s), bad commit known
# good: [567bd8cbc2fe6b28b78864cbbbc41b0d405eb83c] Linux 6.12.63
git bisect good 567bd8cbc2fe6b28b78864cbbbc41b0d405eb83c
# good: [ebdbe19336f26ffe799db842d751745098dc11ff] ASoC: renesas:
rz-ssi: Fix rz_ssi_priv::hw_params_cache::sample_width
git bisect good ebdbe19336f26ffe799db842d751745098dc11ff
# bad: [e79b03d386341e85a4f775e0a864e8aa7633a0a2] HID: intel-ish-hid:
Use dedicated unbound workqueues to prevent resume blocking
git bisect bad e79b03d386341e85a4f775e0a864e8aa7633a0a2
# good: [feb28b6827ece47cce585599a00b02ee579532bc] powercap: fix
sscanf() error return value handling
git bisect good feb28b6827ece47cce585599a00b02ee579532bc
# good: [68495f89a19b6835e388b89b2ffecc0c68f9666c] selftests/landlock:
Fix TCP bind(AF_UNSPEC) test case
git bisect good 68495f89a19b6835e388b89b2ffecc0c68f9666c
# good: [4433ddc3700cea880c383a6ddfc0e2ab697f9bdf] EDAC/x38: Fix a
resource leak in x38_probe1()
git bisect good 4433ddc3700cea880c383a6ddfc0e2ab697f9bdf
# bad: [94b010200a3c9a8420a9063344cedbcd71794c8f] LoongArch: dts:
loongson-2k0500: Add default interrupt controller address cells
git bisect bad 94b010200a3c9a8420a9063344cedbcd71794c8f
# good: [654fa76032eee5df9ce8849bdff840595952c63d] mm/page_alloc: make
percpu_pagelist_high_fraction reads lock-free
git bisect good 654fa76032eee5df9ce8849bdff840595952c63d
# bad: [8140ac7c55e75093a01c6110a2c4025fe7177c57] drm/amd: Clean up kfd
node on surprise disconnect
git bisect bad 8140ac7c55e75093a01c6110a2c4025fe7177c57
# good: [df7a49b328928b6d6b174d954d63721d6f3848a2] LoongArch: Fix PMU
counter allocation for mixed-type event groups
git bisect good df7a49b328928b6d6b174d954d63721d6f3848a2
# bad: [ae5b1d291c814a2884c3d54a56e83bc99052b1eb] drm/amd/display: Bump
the HDMI clock to 340MHz
git bisect bad ae5b1d291c814a2884c3d54a56e83bc99052b1eb
# first bad commit: [ae5b1d291c814a2884c3d54a56e83bc99052b1eb]
drm/amd/display: Bump the HDMI clock to 340MHz

The bad commit certainly seems related:

commit ae5b1d291c814a2884c3d54a56e83bc99052b1eb (HEAD)
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Mon Dec 15 14:08:30 2025 -0600

     drm/amd/display: Bump the HDMI clock to 340MHz

     commit fee50077656d8a58011f13bca48f743d1b6d6015 upstream.

     [Why]
     DP-HDMI dongles can execeed bandwidth requirements on high resolution
     monitors. This can lead to pruning the high resolution modes.

     HDMI 1.3 bumped the clock to 340MHz, but display code never matched it.

     [How]
     Set default to (DVI) 165MHz.  Once HDMI display is identified update
     to 340MHz.

     Reported-by: Dianne Skoll <dianne@skoll.ca>
     Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4780
     Reviewed-by: Chris Park <chris.park@amd.com>
     Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
     Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
     Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
     Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
     (cherry picked from commit ac1e65d8ade46c09fb184579b81acadf36dcb91e)
     Cc: stable@vger.kernel.org
     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
b/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
index b015e80672ec..fcd3ab4b0045 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_hdmi_types.h
@@ -41,7 +41,7 @@
  /* kHZ*/
  #define DP_ADAPTOR_DVI_MAX_TMDS_CLK 165000
  /* kHZ*/
-#define DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK 165000
+#define DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK 340000

  struct dp_hdmi_dongle_signature_data {
         int8_t id[15];/* "DP-HDMI ADAPTOR"*/
diff --git a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
index b6951d7dab49..4e1035c28e18 100644
--- a/drivers/gpu/drm/amd/display/dc/link/link_detection.c
+++ b/drivers/gpu/drm/amd/display/dc/link/link_detection.c
@@ -329,7 +329,7 @@ static void query_dp_dual_mode_adaptor(

         /* Assume we have no valid DP passive dongle connected */
         *dongle = DISPLAY_DONGLE_NONE;
-       sink_cap->max_hdmi_pixel_clock = DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK;
+       sink_cap->max_hdmi_pixel_clock = DP_ADAPTOR_DVI_MAX_TMDS_CLK;

         /* Read DP-HDMI dongle I2c (no response interpreted as DP-DVI
dongle)*/
         if (!i2c_read(
@@ -385,6 +385,8 @@ static void query_dp_dual_mode_adaptor(

                 }
         }
+       if (is_valid_hdmi_signature)
+               sink_cap->max_hdmi_pixel_clock =
DP_ADAPTOR_HDMI_SAFE_MAX_TMDS_CLK;

         if (is_type2_dongle) {
                 uint32_t max_tmds_clk =

Hi

Jaak Ristioja reported the following issue in Debian at
https://bugs.debian.org/1139950 . Part of the original report contains
Debian specific version information, but Jaak did as well a bisecion
for the regression see below:

The reporter did a bisection and found as offending commit:

    drm/amd/display: Bump the HDMI clock to 340MHz

    commit fee50077656d8a58011f13bca48f743d1b6d6015 upstream.

    [Why]
    DP-HDMI dongles can execeed bandwidth requirements on high resolution
    monitors. This can lead to pruning the high resolution modes.

    HDMI 1.3 bumped the clock to 340MHz, but display code never matched it.

    [How]
    Set default to (DVI) 165MHz.  Once HDMI display is identified update
    to 340MHz.

    Reported-by: Dianne Skoll <dianne@skoll.ca>
    Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4780
    Reviewed-by: Chris Park <chris.park@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: Matthew Stewart <matthew.stewart2@amd.com>
    Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit ac1e65d8ade46c09fb184579b81acadf36dcb91e)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Does this ring any bell?

#regzbot introduced: ae5b1d291c814a2884c3d54a56e83bc99052b1eb
#regzbot link: https://bugs.debian.org/1139950

Regards,
Salvatore

Hi

Resending because of typ in mailing list address.

There have been other bandwith related changes.
Would you mind please trying to reproduce on more recent mainline
release, IE 7.1.y?

Also; can you please check both your cable and dongle?  I wonder if one
of them is not compatible with HDMI 1.3?  Are they marketed as
"Standard" or "High Speed"?

Issue also seems to occurs with 7.1.1 (`dmesg -f kern` output attached).

The DisplayPort to HDMI dongle does not have markings on the body to
identify the exact model, but by the looks of it I think it might be a
Vention HBKB0, which seems to be marketed as "1080p@60", "DP male to
HDMI female", "classic" (as opposed to "4K"). According to some
materials, the chip inside is a MXP3361.

The text on the HDMI cable reads "ULTRA HIGH SPEED HDMI™ CABLE -
WWW.HAMA.COM - HAMA GMBH & CO KG 86652 MONHEIM/GERMANY - 82623".

340MHz") on top of v7.1.1 appears to resolve the issue, as I am now able
to get a picture.


PS: My previous e-mail with the attached dmesg-7.1.1.txt.xz file was
bounced from @amd.com addresses: Diagnostic-Code: smtp;550 5.0.350 One
or more of the attachments in your email is of a file type that is NOT
allowed by the recipient's organization.

Unfortunately, reverting that commit will *break* it for me with my Dasung
E-Ink monitor. :(

If it's not possible to detect what the maximum HDMI clock should be, perhaps
a module parameter specifying the HDMI version could be implemented?  Or
a parameter to specify the maximum HDMI clock directly?

Regards,

Dianne.

Jaak, was this ever resolved? It looks like this fell through the
cracks, but maybe I missed something.

If this is still unfixed, I think it likely is best if you report this
to https://gitlab.freedesktop.org/drm/amd/-/work_items/ if you haven't
done so already -- I suspect that is more likely to get the attention of
the amdgpu maintainers. Please drop the link to the ticket here after
submitting the issue.

Ciao, Thorsten

Hi, I don't have any new updates on this yet. As suggested, I've
reported the issue to the amdgpu maintainers here:

https://gitlab.freedesktop.org/drm/amd/-/work_items/5531

Cheers,
Jaak