kern/60759: amdgpu(4) panics during autoconfigure on Renoir APU (Ryzen 5 PRO 4650G) due to unprotected FPU/SSE use in dm_hw_init()

To: kern-bug-people%netbsd.org@localhost,gnats-admin%netbsd.org@localhost,netbsd-bugs%netbsd.org@localhost
Subject: kern/60759: amdgpu(4) panics during autoconfigure on Renoir APU (Ryzen 5 PRO 4650G) due to unprotected FPU/SSE use in dm_hw_init()
From: "keiji%hiemalis.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
Date: Mon, 21 Sep 2026 15:10:00 +0000 (UTC)

>Number:         60759
>Category:       kern
>Synopsis:       amdgpu(4) panics during autoconfigure on Renoir APU (Ryzen 5 PRO 4650G) due to unprotected FPU/SSE use in dm_hw_init()
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 21 15:10:00 +0000 2026
>Originator:     Wada Keiji
>Release:        11.0
>Organization:
>Environment:
NetBSD nbsdar5 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 15:23:12 UTC 2026  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
CPU: AMD Ryzen 5 PRO 4650G with Radeon Graphics (Renoir)
GPU: ATI Technologies product 1636 (PCI ID 1002:1636), rev 0xd9

>Description:
On a system with a Ryzen 5 PRO 4650G (Renoir, PCI ID 1002:1636),
enabling amdgpu(4) in the kernel config causes a kernel panic
during autoconfigure while attaching amdgpu0.

Panic backtrace:

    vpanic() at netbsd:vpanic+0x171
    panic() at netbsd:panic+0x3c
    fpudna() at netbsd:fpudna+0x3c
    Xtrap07() at netbsd:Xtrap07+0xb5
    dm_hw_init() at netbsd:dm_hw_init+0x143
    amdgpu_device_init() at netbsd:amdgpu_device_init+0x1ce4
    amdgpu_driver_load_kms() at netbsd:amdgpu_driver_load_kms+0x50
    drm_dev_register() at netbsd:drm_dev_register+0x168
    amdgpu_attach_real() at netbsd:amdgpu_attach_real+0xba
    config_mountroot_thread() at netbsd:config_mountroot_thread+0x32

A trap type 1 (Device Not Available / #NM) occurs inside
dm_hw_init(). This code runs in the context of
config_mountroot_thread, the dedicated kernel thread used for
autoconfigure, and apparently executes SSE/FPU instructions there.
fpudna() treats this as an invalid FPU access in kernel-thread
context and calls panic().

dm_hw_init() is part of AMD's DC (Display Core) initialization,
which performs floating-point calculations for mode timing, etc.
In upstream Linux, such code is wrapped with kernel_fpu_begin()/
kernel_fpu_end(). It appears that this protection is missing or
non-functional in the NetBSD port when running in an
autoconfigure kernel-thread context.

A very similar issue is documented in FreeBSD, where amdgpu on
Navi/Renoir-and-later GPUs required a dedicated fix to
kernel_fpu_begin/kernel_fpu_end in base:
  https://reviews.freebsd.org/D28061
  "With newer AMD GPUs (>=Navi,Renoir) there is FPU context usage
   in the amdgpu driver. The kernel_fpu_begin/end implementations
   in drm did not even allow nested begin-end blocks."

Workarounds investigated:

1. Loading amdgpu via modload(8) after boot (instead of compiling
   it into the kernel) does NOT panic. This is consistent with the
   hypothesis above, since a normal process context has valid FPU
   state, unlike the autoconfigure kernel thread. However, on a
   GENERIC kernel, genfb(4) has already claimed the same PCI
   device (pci4 dev 0 function 0) as the boot console framebuffer
   by the time amdgpu is modloaded. NetBSD's autoconfigure does
   not support reassigning an already-attached PCI device to a
   different driver at runtime (drvctl(8) detach of genfb0/
   wsdisplay0 fails with "Operation not supported"/"Not
   supported"), so amdgpu0 never attaches to the PCI device at all
   when loaded this way (no amdgpu-related lines appear in dmesg).

2. Changing the default value of amdgpu_dc in amdgpu_drv.c from
   -1 to 0 (equivalent to Linux's amdgpu.dc=0 boot parameter),
   which skips DC initialization entirely, prevents the panic.
   With this change, GFX/SDMA/VCN/JPEG/PSP/SMU all initialize
   successfully:

    [drm] VCN decode and encode initialized successfully(under DPG Mode).
    [drm] JPEG decode initialized successfully.
    SMU is initialized successfully!
    amdgpu0: ring gfx uses VM inv eng 0 on hub 0
    (... additional gfx/comp/kiq/sdma rings initialize normally ...)

   This confirms that the panic is narrowly caused by dm_hw_init()
   (DC initialization) specifically. However, Renoir is a
   DCN-only chip with no legacy (non-DC) display path, so
   disabling DC removes all display/framebuffer functionality.
   amdgpu0 still claims the PCI device (preventing genfb from
   attaching), but provides no console device of its own, so the
   system ends up with no valid console at all. This causes init
   to panic when it tries to open /dev/console:

    breakpoint() at netbsd:breakpoint+0x5
    vpanic() at netbsd:vpanic+0x171
    panic() at netbsd:panic+0x3c
    cnopen() at netbsd:cnopen+0x104
    cdev_open() at netbsd:cdev_open+0x12a
    spec_open() at netbsd:spec_open+0x1e8
    VOP_OPEN() at netbsd:VOP_OPEN+0x3e
    vn_open() at netbsd:vn_open+0x32c
    do_open() at netbsd:do_open+0xb3
    do_sys_openat() at netbsd:do_sys_openat+0x72
    sys_open() at netbsd:sys_open+0x24
    syscall() at netbsd:syscall+0x9a

Given the above, the missing FPU protection in dm_hw_init() (only
triggered when DC is enabled, i.e. the default/normal
configuration) appears to be the sole root cause blocking usable
amdgpu support on Renoir-class APUs under NetBSD.
>How-To-Repeat:
1. On a system with a Ryzen 5 PRO 4650G (or any other Renoir/DCN-
   based AMD APU), start from the GENERIC kernel config and enable:

     amdgpu*       at pci? dev ? function ?
     amdgpufb*     at amdgpufbbus?

2. Build and install this kernel, then boot it.

3. The kernel panics during autoconfigure, within a few seconds
   of boot.

Workaround reproduction:
  - Booting GENERIC (amdgpu disabled) and then running
    `modload amdgpu` does not panic, but amdgpu0 never attaches to
    the PCI device, because genfb(4) has already claimed it as the
    console framebuffer (no amdgpu-related dmesg lines appear).
  - Changing `int amdgpu_dc = -1;` to `int amdgpu_dc = 0;` in
    sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_drv.c and
    rebuilding avoids the original panic; GFX/SDMA/VCN/PSP/SMU
    initialize successfully, but the system panics later in
    cnopen() due to having no valid console device (amdgpu holds
    the PCI device but provides no display output without DC).
>Fix:
Unknown. The Linux compatibility layer under sys/external/bsd/drm2
should be reviewed for its implementation (or lack thereof) of
kernel_fpu_begin()/kernel_fpu_end(), and should likely be fixed to
use fpu_kern_enter()/fpu_kern_leave() so that FPU/SSE use is safe
even from kernel-thread contexts such as config_mountroot_thread.

For reference, see FreeBSD's equivalent fix:
  https://reviews.freebsd.org/D28061
  "With newer AMD GPUs (>=Navi,Renoir) there is FPU context usage
   in the amdgpu driver. The kernel_fpu_begin/end implementations
   in drm did not even allow nested begin-end blocks."

Prev by Date: Re: kern/60584 (vfs_bio: getnewbuf() can deadlock when fresh allocation is refused and no buffer is reclaimable)
Next by Date: Re: bin/60496: Locale-dependent UTF-8 issue over SSH session
Previous by Thread: Re: kern/60584 (vfs_bio: getnewbuf() can deadlock when fresh allocation is refused and no buffer is reclaimable)
Next by Thread: PR/60496 CVS commit: src/lib/libc/stdio
Indexes:

Home | Main Index | Thread Index | Old Index