How to reproduce: 1. kldload radeonkms (no matter whether via rc.conf or manually via console. It loads even if there is no radeon hardware present!). 2. kldunload radeonkms. 3. kldload nvidia. BANG! GPF PANIC! It happens no matter whether sc or vt console are being used. This issue is particularly annoying when you swapped the radeon graphics card for a nvidia one and want reconfigure the system to run with the nvidia, after booting with the rc.conf still containing the radeonkms module kldload. Because, it should not be necessary to have to reboot only because of radeonkms corrupting the kernel. Test system is HP Z800 with FreeBSD 13-RELEASE-p7. Nvidia driver here is 390 (Quadro 2000). But my feeling is the Nvidia driver version will not matter.
Thank you for the report Stefan. Could you please include, as attachments: - pkg version -v output - pciconf -lv output - /var/run/dmesg.boot output - screenshot of the panic message (if available) It would be great, if you can, to enable automatic crash dumps and processing, and to provide a panic backtrace. It may also be useful to build nvidia and drm ports WITH_DEBUG before doing so.
Dear Kubilay! Honestly, I think it is unnecessary to collect all these attachments you requested. I did some more tests. The amdgpu and i915kms modules behave fine. They do not crash the computer. Only radeonkms behaves bad. And it does not matter which nvidia version you use. Having previously loaded radeonkms panics the computer, no matter whether you load 340, 390 or the current (470) driver. It is so easy to reproduce, so, again, I doubt it makes sense to post these attachments. I will change the bug description accordingly.
BTW, after I posted the last comment, I thought of testing whether crashing the kernel might "work" also if instead of nvidia, I kldload amdgpu or i915kms after kldunloading radeonkms. And yes, it "works", too. So I guess I have to change the PR title again...
Does the commit that's linked from <https://github.com/freebsd/drm-kmod/issues/168#issuecomment-1142618864> help to think about a possible fix here?