Dear Maintainers and readers,

I have come across what I think is a kernel bug regarding how during system boot the video-mode for the console is being selected. Inspection of logs with debugging enabled show that in my particular case kernel selects 4k resolution at 144Hz. The supported maximum of my GPU however is 4k at 60Hz only, because DisplayPort 1.4 is available, but DSC is not.

I will provide hardware details and software versions below, with detailed findings at the end. If you have any ideas how to resolve this, I am happy to try a patch and report back.

# Hardware Info: SolidRun HoneyComb Workstation - LX2160A (16x Cortex-A72) - 32GB DDR4-3000 memory - ACPI ADATA SX8200 NVME Radeon Pro WX2100 - DisplayPort 1.4 - 1x full-size port, 2x mini ports EVE Spectrum ES07D03 display (max. 4k 144Hz)

# Software Info: openSUSE Tumbleweed Linux 5.15.7-1-vanilla aarch64 Linux 5.15.7-1-default aarch64 Linux 5.15.5-1-default aarch64 Mesa 21.3

# Work-Arounds: I *can* get to a functional plasma wayland session by forcing a supported video mode for both the console and X (because sddm doesn't do wayland):

- kernel cmdline: video=DP-3:3840x2160@60

- xorg.conf.d: Section "Monitor" Identifier "DisplayPort-2" ModeLine "3840x2160__60.0" 594.00 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync Option "PreferredMode" "3840x2160__60.0" EndSection

# Details The issue manifested itself first as soon as Linux takes over the graphics card from UEFI. That is both UEFI and grub menus show up fine, but then once Linux starts the display turns black - but stays on for a while. The backlight makes it shine slightly - till eventually a NO SIGNAL message shows up before it enters a standby mode.

poking around /sys showed that Linux recognizes a display is connected, and that it knows what modes that one supports: cat /sys/class/drm/card0-DP-3/status connected cat /sys/class/drm/card0-DP-3/modes 3840x2160 ... 2560x1440 2560x1080 ...

Then I tried to force a video-mode that I expected to work, and booted with video=DP-3:3840x2160@60 to choose what I believe is the maximum supported by this particular GPU. Now, console messages of the boot process show up properly, and after a few seconds the display switches to the 4k resolution - eventually leading to the console login prompt. --> This is where I know there is a mode that works, and Linux does not pick it by default.

So I enabled debug output for the drm module by booting with amdgpu.dcdebugmask=0x4 drm.debug=0x104 <-- I figured that would be all the interesting pieces. And sure enough I can see all the modes being printed, one being picked - and a rather sane error message: [ 10.186899] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 144 1296000 3840 3888 3920 4000 2160 2168 2178 2250 0x48 0x9 [ 10.186959] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x48 0x5 [ 10.197301] [drm:drm_client_modeset_probe [drm]] desired mode 3840x2160 set on crtc 51 (0,0) [ 10.242536] [drm:create_validate_stream_for_sink [amdgpu]] Mode 3840x2160 (clk 1296000) failed DC validation with error 10 (No DP link bandwidth) [ 10.244183] [drm:dce112_validate_bandwidth [amdgpu]] dce112_validate_bandwidth: Bandwidth validation failed! --> Clearly some subsystem knows the chosen video mode is not supported here. But it never gets around to trying another mode, e.g. the *second* mode listed in edid (which would work).

I am attaching to this mail the dmesg produced with log_level=9 drm.debug=0x11F video=DP-1:d video=DP-2:d (unused ports forced disabled, and most drm debug messages enabled)

I have also tried swapping the connectors on the card: I tried both DP-3 (the full-size connector) and DP-1 (one of the two mini connectors) but the behaviour is the same.

Further Xorg also auto-selects the 144Hz mode according to its log-file.

Finally I also attach output of the drm_info tool from https://github.com/ascent12/drm_info

Yours sincerely Josua Mayer