Dear Maintainer,

I am reporting an amdgpu regression affecting three identical Dell OptiPlex 7090 systems.

System:
- Dell OptiPlex 7090
- Intel Core i7, Rocket Lake generation

Integrated GPU:
- Intel RocketLake-S GT1 / UHD Graphics 750
- PCI ID 8086:4c8a
- Driver: i915

Discrete GPU:
- AMD Lexa / Polaris12
- PCI ID 1002:6987
- Subsystem ID 1028:1713
- Driver: amdgpu

The last known good Debian kernel is 6.12.74+deb13+1-amd64. The first known bad is 6.12.85+deb13-amd64.

With 6.12.74, the system boots normally and the AMD GPU binds successfully.

With 6.12.85 and later tested kernels, a normal boot hangs during graphics initialization. Global nomodeset allows the OS to boot, indiciating the failure occurs during graphics initialization, but it makes the AMD GPU unavailable. Using amdgpu.dc=0 allows 6.12.85 to finish booting, but the amdgpu PCI probe fails. The AMD GPU remains unbound and no AMD card or render node is created.

The expected result is to be able to boot newer debian 13 kernel versions without having to use workarounds (ie. I want to use my AMD graphics card for my displays).

Bad-kernel failure:
6.12.85+deb13-amd64

Command line parameter used to reach a usable system:

amdgpu.dc=0

The initial amdgpu probe reaches VRAM, GTT, SMU and UVD firmware initialization, then fails during the UVD v6 ring test:

[drm] UVD is enabled in VM mode
[drm] UVD ENC is enabled in VM mode
amdgpu 0000:01:00.0: amdgpu: VRAM: 4096M
amdgpu 0000:01:00.0: amdgpu: GART: 256M
[drm] Found UVD firmware Version: 1.130 Family ID: 16
amdgpu 0000:01:00.0: ERROR ring uvd test failed (-110)
[drm] ERROR hw_init of IP block <uvd_v6_0> failed -110
amdgpu 0000:01:00.0: amdgpu: Fatal error during GPU init
amdgpu 0000:01:00.0: probe with driver amdgpu failed with error -110

Error -110 is ETIMEDOUT.

After failed initialization, cleanup produces additional errors, including KIQ/KCQ failures. The associated AMD HDMI-audio function then cannot return from D3cold:

snd_hda_intel 0000:01:00.1: Unable to change power state from D3cold to D0, device inaccessible
snd_hda_intel 0000:01:00.1: CORB reset timeout#2, CORBRP = 65535

The D3cold errors occur after the UVD ring timeout and appear to be a consequence of failed GPU initialization.

With the bad kernel:

amdgpu.ko is present and loaded
the amdgpu module has use count zero
PCI device 0000:01:00.0 remains unbound
/sys/bus/pci/devices/0000:01:00.0/driver is absent
lspci shows “Kernel modules: amdgpu” but no “Kernel driver in use”
no AMD card or render node exists under /dev/dri/by-path

Control test with last known good kernel:
6.12.74+deb13+1-amd64

Command-line parameter:

amdgpu.dc=0

On this kernel, the same hardware binds successfully:

Kernel driver in use: amdgpu

The AMD DRM nodes are created:

pci-0000:01:00.0-card
pci-0000:01:00.0-render

UVD initializes successfully:

[drm] UVD is enabled in VM mode
[drm] UVD ENC is enabled in VM mode
[drm] Found UVD firmware Version: 1.130 Family ID: 16
[drm] UVD and UVD ENC initialized successfully.

This demonstrates that amdgpu.dc=0 itself does not inherently prevent this GPU from initializing. The UVD failure appears only with the newer kernel.

Other diagnostic results:
- amdgpu.runpm=0 does not change the failure.
- Firmware packages have already been reinstalled and this did not change the result.
- No driver_override is configured.
- No competing radeon, vfio-pci, nouveau or NVIDIA driver is registered for the device.
- There is no amdgpu blacklist or VFIO binding rule.
- Manual rebinding after the initial failed probe does not recover the card. The device is already inaccessible in D3cold and PCI configuration reads return invalid values, so the manual-bind errors appear secondary.
- A complete cold power-off was performed before the runpm test.

Attachments:
I am attaching:
- full and focused kernel logs from 6.12.85
- successful comparison logs from 6.12.74
- uname and kernel command lines
- lspci -nnk and lspci -vvnn output
- DRM-node and PCI-binding state
- relevant package versions
- system model and BIOS version

I used AI to draft most of this report. Hopefully its not too bad xD

Control: tags -1 + moreinfo upstream

As you seem to fairly easy reproduce the issue, can you pleas bisect
the kernel between 6.12.74 and 6.12.85 upstream and report back which
commits breaks the usecase?

Are you familiar with bisecting the kernel or do you need instructions
on how to do it?

Regards,
Salvatore

Attached are the diagnostic files referenced in my original report.

They include:

   - kernel logs from the affected 6.12.85 kernel with amdgpu.dc=0
   - comparison logs from the working 6.12.74 kernel
   - PCI and driver-binding information
   - DRM-node information
   - package, BIOS, and system details

The important comparison is:

   - 6.12.74 with amdgpu.dc=0: amdgpu binds and UVD initializes successfully
   - 6.12.85 with amdgpu.dc=0: the UVD v6 ring test times out with -110,
   and amdgpu probe fails

No manual rebind was attempted in the attached affected-kernel boot log.