On 10/2/26 14:25, Johannes Stezenbach wrote:
On Fri, Oct 02, 2026 at 11:12:10AM -0500, Mario Limonciello wrote:
On 10/2/26 10:47, Alex Deucher wrote:
On Fri, Oct 2, 2026 at 8:52 AM Johannes Stezenbach <[email protected]> wrote:
I have one Asrock Deskmini X600 with Ryzen 8700G.
Recently a BIOS update was released which updates
AGESA ComboAM5 from 1.2.0.3g to 1.3.0.1a.
https://www.asrock.com/nettop/AMD/DeskMini%20X600%20Series/index.asp#BIOS
The result is boot failure before any message could be printed
with my self-built kernel, which has the amdgpu driver built-in.
However, a Debian rescue image with kernel 7.2.8 could boot
(in text mode or vesa graphics mode).
Using the rescue system, I installed the Debian kernel 7.2.8,
it can boot but hangs after the amdgpu module is loaded
(no error message or crash output).
It can boot successfully with module_blacklist=amdgpu.
https://packages.debian.org/forky/linux-image-7.2.8+deb14-amd64
If you have any ideas what to try please let me know soon,
otherwise I'll have to downgrade to the previous BIOS version.
Can you get ssh access to the system? Can you boot without amdgpu and
then log in remotely and manually load amdgpu and get the dmesg
output?
Depending upon how early it hangs, anything saved into the journal from
previous boot? You can try:
# journalctl -k -b-1
Also; what is the version of your DMCUB
(/lib/firmware/amdgpu/dcn_3_1_4_dmcub.bin.zst)?
You can use this script to parse it:
https://gitlab.com/kernel-firmware/linux-firmware/-/blob/main/contrib/get_amdgpu_fw_version.py?ref_type=heads
If you upgrade to the latest upstream version does it help?
I have the latest upstream version (it is in Debian sid):
$ ./get_amdgpu_fw_version.py /lib/firmware/amdgpu/dcn_3_1_4_dmcub.bin
dcn_3_1_4_dmcub.bin: DMCUB FW
ip_major = 3 (0x3)
ip_minor = 1 (0x1)
ucode_version = 134242816 (0x8006200)
ucode_bytes = 350240 (0x55820)
crc32 = 3448435613 (0xcd8af39d)
--------------------------------
Detailed uCode version:
major = 8 (0x8)
minor = 0 (0x0)
revision = 98 (0x62)
is_test = 0 (0x0)
is_vbios = 0 (0x0)
hotfix = 0 (0x0)
Now it gets a bit mysterious: The Debian kernel booted
successfully a few times in a row, while earlier today it
always failed in a few tries. But eventually I reproduced the
failure and got the attached log.
Screen output stopped after the "[drm] ATOM BIOS:
113-PHXGENERIC-001..." line (i.e. before "Console: switching to
colour dummy device 80x25").
I notice now that I still have the amd_iommu_intr=legacy option
which I needed to fix hibernation, let me know if you think
it's related. For all I know I still need it.
https://bugzilla.kernel.org/show_bug.cgi?id=221036
However, my self-built kernel still crashes early after I changed
amdgpu to be a loadable module. So there is something else going
on, but lets concentrate on the andgpu failure with the Debian kernel.
Best Regards,
Johannes
Here's your first indication of a problem:
[ 13.423543] amdgpu 0000:6e:00.0: [drm:amdgpu_ring_test_helper
[amdgpu]] *ERROR* ring mes_kiq_3.1.0 test failed (-110)
[ 13.423719] amdgpu 0000:6e:00.0: hw_init of IP block <gfx_v11_0>
failed -110
[ 13.423723] amdgpu 0000:6e:00.0: amdgpu_device_ip_init failed
[ 13.423727] amdgpu 0000:6e:00.0: Fatal error during GPU init
[ 13.423732] amdgpu 0000:6e:00.0: finishing device.
Basically there is a graphics ring buffer test that happens and fails.
Then the hardware init fails as a result of that failing.
From your logs the notable versions:
[ 0.414349] AGESA: AGESA!V9 ComboAm5PI 1.3.0.1a
and
smu fw version = 0x004c6700 (76.103.0)
Was the only think you changed BIOS? Or did you happen to upgrade
linux-firmware recently too and that could have been the cause?
Can you downgrade back to existing BIOS and see if it's OK?
