You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I recently upgraded to FreeBSD 14.2 from 14.1 and found that my amdgpu driver would crash upon loading.
My CPU is an AMD Ryzen 9600X
My GPU is an AMD Radeon PRO W6400.
This combination worked fine before the upgrade. After suspecting some foul play and downgrading drm-kmod etc, I found some of the bugs here about not supporting Raphael GPUs and it sparked a little light.
Looking at the output of fwget -v, there were at least two matched to amd:
Trying to match device 0x7422 in class video and vendor amd with pci_video_amd
Trying to match device 0x13c0 in class video and vendor amd with pci_video_amd
Now, the built in GPU is not used, nothing is plugged in. Previously I guess this iGPU was ignored, however now it crashes, seemingly as it detects an unsupported GPU and refuses to proceed.
By disabling the iGPU in the BIOS, I was able to get the amdgpu driver to load again and resume my activities.
I appreciate it would not be able to detect that there is nothing plugged in, but it seems relatively poor form to crash on the unsupported GPU when there is a perfectly good supported one sitting there as well to make use of.
Perhaps we need / have to document a way to target one GPU over the other, instead of having to rely on a physical BIOS tweak, as pertaining to DRM-KMOD specifically. I suspect there might be a way in /boot/loader.conf to prefer attaching to one PCIe device over the other (and disabling the other...). Maybe we can do it by spoofing a PCI-passthrough via pptdevs="a/b/c" -- where the device a/b/c is the one you want to block out / disable. I believe there is a way to force Xorg to target only one GPU device, thus allowing you to ignore the iGPU on the CPU.
For reference, I have a 7950X3D (also crazy fast) with an NVidia RTX 3070, where I have left the iGPU enabled in BIOS, and have no issues -- and I never load the amdgpu driver anyways.
That 9600X is fast isn't it?! I can't wait to get my hands on a 9950X3D. The 9700X is ridiculously quick already.
How are you liking the Radeon Pro W6400? It is high on my list to acquire...
The most user friendly thing to do would be a pseudocode approach of:
collect all GPUs available
if amount of GPUs > 1:
filter out the unsupported GPUs
if remaining GPU is unsupported:
still crash as before
continue along with remaining supported GPU
The W6400 is great for my purposes, which is to drive a couple of 4k screens at 60Hz with some of the lowest relative power consumption going, the only wrinkles have been the FreeBSD support for RNA2, and this issue.
Describe the bug
I recently upgraded to FreeBSD 14.2 from 14.1 and found that my amdgpu driver would crash upon loading.
My CPU is an AMD Ryzen 9600X
My GPU is an AMD Radeon PRO W6400.
This combination worked fine before the upgrade. After suspecting some foul play and downgrading drm-kmod etc, I found some of the bugs here about not supporting Raphael GPUs and it sparked a little light.
Looking at the output of
fwget -v
, there were at least two matched toamd
:Now, the built in GPU is not used, nothing is plugged in. Previously I guess this iGPU was ignored, however now it crashes, seemingly as it detects an unsupported GPU and refuses to proceed.
By disabling the iGPU in the BIOS, I was able to get the
amdgpu
driver to load again and resume my activities.I appreciate it would not be able to detect that there is nothing plugged in, but it seems relatively poor form to crash on the unsupported GPU when there is a perfectly good supported one sitting there as well to make use of.
FreeBSD version
Output of
uname -aKU
:PCI Info
pciconf -lv
Paste the output of
pciconf -lv
DRM KMOD version
To Reproduce
Steps to reproduce the behavior:
Workaround:
Disable the iGPU forcibly in the BIOS.
Screenshots
No screenshots are possible as the screen goes blank and locks up.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: