[drm] *ERROR* `lttpr_caps` `phy_repeater_cnt` is `0x0`, forcing it to `0x80` in journal. Why?

When I reboot, I often see something akin to:

amdgpu 0000:59:00.0: [drm] *ERROR* lttpr_caps phy_repeater_cnt is 0x0, forcing it to 0x80

Has anyone else seen it? Do you know why it’s repeatedly posted to the TTY in boot-dmesg mode?

I ask because checking the boot log for repetitions has already allowed me to report gitlab.freedesktop.org/drm/amd/-/issues/3248, so I’d like to ascertain whether it’s expected, in order to reduce the superfluous logs further.

This persists across an OS reinstallation.

Consequently, I’ve reported it (albeit upstream, hopefully not erroneously):

A competent explanation from an OpenAI LLM (presumably GPT4.0) states:

  1. amdgpu 0000:59:00.0: [drm] *ERROR* lttpr_caps phy_repeater_cnt is 0x0, forcing it to 0x80.
    

    Component

    This relates to LTTPR (Link Training Tunable PHY Repeater), part of DisplayPort 1.4+ spec.

    Cause

    The GPU queries the capabilities of the DisplayPort link (via DPCD registers) and finds the repeater count (phy_repeater_cnt) to be 0x0, which is invalid or unexpected.

    Effect

    The driver forcibly sets it to 0x80, a default value (meaning one repeater with one segment).

    Implication

    This typically indicates a problem in DisplayPort signal negotiation, DP-to-HDMI adapters, hubs, or cables.

  2. amdgpu 0000:59:00.0: [drm] Cannot find any crtc or sizes
    

    Component

    CRTC = Cathode Ray Tube Controller, a part of the kernel’s DRM/KMS display pipeline.

    Cause

    The GPU is trying to assign a display to a CRTC but can’t find a compatible one. This usually happens when:

    1. No display is detected or connected.

    2. There’s a miscommunication between the GPU and the display hardware (especially via DisplayPort).

    3. Something is polling for a new display repeatedly and failing.

[1]


  1. chatgpt.com/share/6834cd54-a4f4-8006-9ccb-5ed21e97ffcf [2] ↩︎

  2. chatgpt.com/c/6834c61b-1c64-8006-907b-0177ccb2cca4 ↩︎