On Sun, Sep 27, 2026 at 05:40:26PM +0000, Christian Herklotz wrote: > >Synopsis: amdgpu fails to map 12GB VRAM aperture with resizable BAR; X > >then crashes kernel > >Category: kernel > >Environment: > System : OpenBSD 7.9 > Details : OpenBSD 7.9-stable (GENERIC.MP) #0: Sun Sep 27 06:22:38 UTC > 2026 > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > Hardware : HP OMEN by HP 40L Gaming Desktop GT21-0xxx, BIOS F.34 > Ryzen 7 5800X, AMD Radeon RX 6700 XT (Navi 22, 1002:73df, > subsys 103c:892a), resizable BAR enabled (not configurable) > Firmware : amdgpu-firmware-20260519 > Note : Bug seen with stock OpenBSD 7.9 GENERIC.MP#11 (syspatch > 021). > The kernel shown above is a local 7.9-stable build with > the workaround described under >Fix. > >Description: > The BIOS of this HP OEM machine has resizable BAR permanently enabled > and offers no option to turn it off. BAR0 of the GPU is 16GB: > > 0x0010: BAR mem prefetchable 64bit addr: 0x0000007800000000/0x400000000 > > so visible_vram_size is 0x2ff000000 (~12GB). amdgpu fails at boot: > > [drm] *ERROR* visible_vram_size 2ff000000 or aper_base_kaddr 0x0 is not > initialized. > drm:pid0:psp_sw_init *ERROR* Failed to process memory training! > drm:pid0:amdgpu_device_ip_init *ERROR* sw_init of IP block <psp> failed > -22 > drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed > drm:pid0:amdgpu_driver_load_kms *ERROR* Fatal error during GPU init > WARNING !amdgpu_irq_enabled(adev, src, type) failed at > /usr/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_irq.c:650 > efifb0 at mainbus0: 3840x2160, 32bpp > > 1) In the __OpenBSD__ branch of amdgpu_ttm_init() the aperture is > mapped with bus_space_map(memt, aper_base, visible_vram_size, > LINEAR|PREFETCHABLE). For a 12GB aperture this fails (either > extent_alloc_region() or km_alloc() in amd64 bus_space_map()); > the error is silently turned into aper_base_kaddr = NULL. > psp_v11_0_memory_training() then refuses to run and the whole > init fails. Linux ioremap_wc()s the same range fine. > The long memory training only needs the first > BIST_MEM_TRAINING_ENCROACHED_SIZE (64MB) of the aperture. > > Confirmed: a 7.9-stable kernel built with only > int amdgpu_vis_vram_limit = 256; > in amdgpu_drv.c attaches fine on the same machine: > amdgpu0: NAVY_FLOUNDER GC 10.3.2 40 CU rev 0x00 > amdgpu0: 3840x2160, 32bpp > wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation) > and X works with acceleration: > OpenGL renderer string: AMD Radeon RX 6700 XT (radeonsi, > navi22, LLVM 19.1.7, DRM 3.64, 7.9) > > 2) After the fatal init error amdgpu_forcedetach() only reattaches > efifb on EFI systems; drm0 stays attached and /dev/dri/card0 and > renderD128 remain openable (drmopen() only checks dev_private). > Starting X then crashes the machine; ~/.local/share/xorg/Xorg.0.log > is left empty. ddb output: > > drm_sched_entity_init: called with uninitialized scheduler > drm_sched_entity_init: called with uninitialized scheduler > drm:pid68205:drm_sched_job_init *ERROR* drm_sched_job_init: entity has > no rq! > uvm_fault(0xfffffd83be888190, 0x210, 0, 1) -> e > kernel: page fault trap, code=0 > Stopped at amdgpu_bo_unreserve+0x1a: movq 0x210(%rdi),%rdi > TID PID UID PRFLAGS PFLAGS CPU COMMAND > *321458 68205 1000 0x2 0 1K Xorg > amdgpu_bo_unreserve(0) at amdgpu_bo_unreserve+0x1a > amdgpu_vm_init(ffff800000530000,ffff800001693000,0,0) at > amdgpu_vm_init+0x510 > amdgpu_driver_open_kms(ffff800000530058,ffff8000015bb400) at > amdgpu_driver_open_kms+0x145 > drm_file_alloc(ffff8000002a9f00) at drm_file_alloc+0x251 > drmopen(15700,3,2000,ffff80005b7914f8) at drmopen+0x12c > spec_open_clone(ffff80005b7de8c8) at spec_open_clone+0x166 > spec_open(ffff80005b7de8c8) at spec_open+0x198 > VOP_OPEN(fffffd83bd1f4570,3,fffffd843eb611a0,ffff80005b7914f8) at > VOP_OPEN+0x57 > vn_open(ffff80005b7deae0,3,0) at vn_open+0x326 > doopenat(ffff80005b7914f8,ffffff9c,79f1ea5d4d40,2,0,0,58ea7161cfd4961b) at > doopenat+0x229 > sys_open(ffff80005b7914f8,ffff80005b7ded40,ffff80005b7decc0) at sys_open+0x38 > syscall(ffff80005b7ded40) at syscall+0x5f9 > Xsyscall() at Xsyscall+0x128 > end of kernel > > (No further ddb commands possible: the machine has no PS/2 > controller and the USB keyboard does not work in ddb, so no > "ps"/"show registers"/"boot dump". Same reason "boot -d" is > unusable: "kbc: cmd word write error".) > >How-To-Repeat: > Boot OpenBSD 7.9 on a Navi 2x card with resizable BAR enabled > (BAR0 larger than the VRAM aperture that bus_space_map can map), > then run startx. > >Fix: > Workaround: set amdgpu_vis_vram_limit to 256 (MB) in a custom > kernel (tested, see above). Setting it from ddb at boot is not > possible on this machine: there is no PS/2 controller > ("kbc: cmd word write error") and the USB keyboard does not > work in ddb. > > Suggestions: > - limit the size of the aperture mapping in amdgpu_ttm_init() on > OpenBSD (or fall back to a smaller mapping), and print an error > when bus_space_map() fails instead of silently continuing; > - after a fatal init error, detach drm0 / make drmopen() fail so > userland cannot reach a half initialised device.
handled back in June sys/arch/amd64/include/vmparam.h 1.26 ---------------------------- revision 1.26 date: 2026/06/22 00:27:33; author: jsg; state: Exp; lines: +2 -2; commitid: yHDcTRKnwqjch7jt; raise the size of amd64 kernel virtual address space from 4G to 512G This allows mapping all of VRAM on recent Radeon cards where the PCI BAR size is the full (> 4G) size. Reported by Petre Rodan, who has a Radeon RX 6800 with 16G of VRAM. feedback from claudio@ ok kettenis@ ---------------------------- sys/uvm/uvm_map.c 1.356 ---------------------------- revision 1.356 date: 2026/06/25 08:27:34; author: kettenis; state: Exp; lines: +2 -3; commitid: 12PxT3YjnVKEe5Fq; Initialize uvm_maxkaddr to VM_MIN_KERNEL_ADDRESS. This fixes a problem where uvm_map() with the UVM_FLAG_FIXED flag would miscalculate the amount to grow the kernel pmap if uvm_maxkaddr was still zero, which happens on amd64 (and possibly other architectures that use PMAP_STEAL_MEMORY). This would result in the kernel pmap growing to its maximum which would consume all memory on small memory machines now that we've given amd64 512G of KVA. ok deraadt@ ----------------------------
