well, in the end I could workaround this bug  by trial&error in the following sequence :
1. — solution (important to install BOTH drm&firmware via ports)—
pkg delete [everything drm-kmod & gpu-firmware-kmod]
pkg autoremove
cd /usr/ports/graphics/drm-kmod
make install
cd /usr/ports/graphics/gpu-firmware-kmod
make install

Maybe the above is a known sequence for some people who hit this issue but why not fix this bug

2.—while worked around it  for now  I think I’ll leave this bugzilla open since the following related is for sure a kernel bug  :

This should be the (existing)correct way to prevent kernel crash/attack: 
root@fbsd5pro:~ # kldunload  amdgpu_renoir_asd_bin.ko
kldunload: can't unload file: Device busy
…with the addition of console-message :
kldunload: attempt to unload file that was loaded by the kernel

But :
 try to:
 kldunload amdgpu,
 ouch, massive crash(system tries to goto init1 and even fails that attempt & freezes)

3.—
Also I would suggest to „ forbid“ to install drm-kmod & gpu-firmware-kmod via pkg 
since version incompatibilities or whatever crap will massively pollute the system and will crash X11 or kernel panic  .
Instead an attempt of using pkg should ONLY spit out a warning message AND instructions to do it correctly via ports.
I know there is a message AFTER(why not before?) installation like :
If not good for your OS- version then rebuild ( w/o details howto remove the crap and rebuild)
of course: fix instead of warn is even better :-)


O.K., above only as a conceptual approach , for me it’s fixed thanks to some hints from the mailing list, thx :-)
.. if someone wants to close this report, O.K. for me

Thx @Mark Linimon for redirecting this to X11@ , Regards

(In reply to Klaus Küchemann from comment #1)
last but no least quoting myself :
<<2.—while worked around it  for now  I think I’ll leave this bugzilla open since the following related is for sure a kernel bug >>

of course I know it isn`t a kernel bug but an X11-bug or similar...
but maybe the kernel should protect itself by rejecting especially attacks like kldunload amdgpu..
o.k., it`s loaded by rc.conf and I am always root ..
if the unload is protected by root(su)-only forget it :-)

I have hit the same issue on "CPU: 12th Gen Intel(R) Core(TM) i5-1235U (2496.00-MHz K8-class CPU)"

The old version is:
 main-n287169-6d9bc46cd7fc: Wed Jul  1 16:51:31 PDT 2026     root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
A significant difference is that I was running 612, not 66. I was surprised that the new source drm-66-kmod file built with the new kernel sources works fine with the month-old kernel. I had not touched world when booting the old kernel. It booted normally, though with several ugly looking errors which I do not believe were related, but tied to starting IPv6 and Bluetooth. I'm guessing BZ has updated things in this area.

Just now I rebuilt drm-612-kmod reinstalled it and rebooted. I It booted normally, though with several ugly looking errors which I do not believe were related, but tied to starting IPv6 and Bluetooth. I'm guessing BZ has updated things in this area.t booted fine and Mate came up fine. (IPv6 also is working.)

Here is the crash:
drmn0: successfully loaded firmware image 'i915/adlp_dmc.bin'
drmn0: [drm] Finished loading DMC firmware i915/adlp_dmc.bin (v2.20)
drmn0: [drm] [ENCODER:244:DDI B/PHY B] unusable PPS, disabling eDP
panic: Assertion td->td_lkpi_task == NULL failed at /usr/src/sys/compat/linuxkpi/common/src/linux_current.c:85
cpuid = 9
time = 1785681088
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x36/frame 0xfffffe00eb603480
vpanic() at vpanic+0x149/frame 0xfffffe00eb6035b0
panic() at panic+0x43/frame 0xfffffe00eb603610
linux_alloc_current() at linux_alloc_current+0x2e3/frame 0xfffffe00eb603660
drm_framebuffer_init() at drm_framebuffer_init+0x199/frame 0xfffffe00eb603690
intel_framebuffer_init() at intel_framebuffer_init+0x792/frame 0xfffffe00eb6036e0
intel_crtc_initial_plane_config() at intel_crtc_initial_plane_config+0x7d5/frame 0xfffffe00eb603810
intel_display_driver_probe_nogem() at intel_display_driver_probe_nogem+0x2ae/frame 0xfffffe00eb603850
i915_driver_probe() at i915_driver_probe+0x634/frame 0xfffffe00eb603890
linux_pci_attach_device() at linux_pci_attach_device+0x55b/frame 0xfffffe00eb6038f0
device_attach() at device_attach+0x466/frame 0xfffffe00eb603940
bus_generic_driver_added() at bus_generic_driver_added+0x90/frame 0xfffffe00eb603960
devclass_driver_added() at devclass_driver_added+0x29/frame 0xfffffe00eb603990
devclass_add_driver() at devclass_add_driver+0x138/frame 0xfffffe00eb6039d0
_linux_pci_register_driver() at _linux_pci_register_driver+0xc1/frame 0xfffffe00eb603a00
i915kms_evh() at i915kms_evh+0x272/frame 0xfffffe00eb603a20
module_register_init() at module_register_init+0xb0/frame 0xfffffe00eb603a50
linker_load_module() at linker_load_module+0xcf7/frame 0xfffffe00eb603d60
kern_kldload() at kern_kldload+0x172/frame 0xfffffe00eb603db0
sys_kldload() at sys_kldload+0x67/frame 0xfffffe00eb603df0
amd64_syscall() at amd64_syscall+0x17c/frame 0xfffffe00eb603f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00eb603f30
--- syscall (304, FreeBSD ELF64, kldload), rip = 0x1861805f36a, rsp = 0x1861598e3f8, rbp = 0x1861598e970$
KDB: enter: panic

(In reply to rkoberman from comment #3)
<<A significant difference is that I was running 612, not 66>>

Yes, /usr/ports/graphics/drm-kmod last but not least also chooses 
612 for my system and is running fine now. No clue how 66 came to the system in the past.. that`s why I think(or guess) that: 
—
pkg delete [everything drm-kmod & gpu-firmware-kmod]
pkg autoremove
cd /usr/ports/graphics/drm-kmod
make install
cd /usr/ports/graphics/gpu-firmware-kmod
make install
—
 is hopefully a safe workaround for now for everyone,

regardless the current head version(which here was 1600019 ).
Also the mentioned  mismatch warning (graphics/drm-66-kmod/files/pkg-message.in )
said(or maybe lied:-) that my OS-version is O.K.
I`m not aware of the code-related details of the real root cause of this bug 
And a PR on phab or git for correction of pkg-message.in would also not prevent anybody from running into this trap because that message comes too late(after polluting the system) (and is even wrong). 

Regards

My battle continues with no improvement.
I have deleted all drm-kmod and gpu-firmware-* software, done pkg autoremove and reinstalled drm-612-kmod and gpu-firmware-intel-kmod. Nothing improved. With drm-612-kmod, attempting to run mpv resulted in a GPU lockup as soon as the video tried to start playing. No other messages were displayed or logged.

Repeated except install drm-66-kmod. Again no change from that kmod in the past. Difference from 612 ias that the GPU does not lock up. Instead I get three of the error:
[vo/gpu-next/libplacebo] Masking `storable` from wrapped texture because the corresponding format 'bgra8' does not support PL_FMT_CAP_STORABLE
followed by a long stream of
[vo/gpu-next/libplacebo] vkQueueSubmit2: VK_ERROR_UNKNOWN (../src/vulkan/command.c:533)

I should note that, until the recent update of mesa, MPV simply reported that vulkan was not functional and played the video, probably using vaapi. 

I think the problem stems from mesa being fixed but drm-kmd (either 66 or 612 being broken, but in different ways.

Another thing that locks up 615 is virtualbox. If I start or save a VM, part way through the operation, the GPU locks up. If a switch to another workspace, it does not happen. It either starts or saves normally.

System is 12th Gen Intel(R) Core(TM) i5-1235U (2496.00-MHz K8-class CPU)
GPU is Intel:
vgapci0@pci0:0:2:0:     class=0x030000 rev=0x0c hdr=0x00 vendor=0x8086 device=0$
    vendor     = 'Intel Corporation'
    device     = 'Alder Lake-UP3 GT2 [Iris Xe Graphics]'

I have multiple tools written to use mpv capability not available elsewhere and I have been unable to figure a way to write it for vlc as it lacks the capability to use a UNIX pipe to talk to it while still having keyboard access.