Help with NVIDIA drm set up

gnath said:
x11/nvidia-driver-550.127.05.1402501 and graphics/nvidia-drm-66-kmod are in ports tree. But the graphics/nvidia-drm-66-kmod failed to build on my 14-STABLE box.
Click to expand...
It's just as intended by the maintainer.

graphics/nvidia-drm-66-kmod depends on graphics/drm-66-kmod.
Code: 
BUILD_DEPENDS+=    ${KMODDIR}/drm.ko:graphics/drm-66-kmod
RUN_DEPENDS+=    ${KMODDIR}/drm.ko:graphics/drm-66-kmod

And graphics/drm-66-kmod is (currently, actually correct or not) restrected with fairly recent main branch (aka 15-Curret) of FreeBSD, thus, fail on stable/14.
Code: 
.if ${OPSYS} == FreeBSD && !( ${OSVERSION} >= 1500031 )
IGNORE=        not supported on older than 1500031, no kernel support
.endif
.if ${OPSYS} != FreeBSD
IGNORE=        not supported on anything but FreeBSD (missing linuxkpi functionality)
.endif
 
gnath said:
I am now on my 14-STABLE old box and have installed graphics/nvidia-driver-570.124.04.1402504. After that I had problem with suspend/resume. I have installed this from ports tree with default options. Now remaking the port with option "ACPI_PM=on" and followed the new pkg-message regarding "GSP firmware" , the problem is not there.
Click to expand...
Did you restarted OS after you edited /boot/loader.conf?
This file is handled by loader, before kernel starts. So does not take effect until the OS is restarted.
 
gnath said:
Yes, I have rebooted the box and logged into WM.
Click to expand...
Forgot to confirm (as you mentioned GSP firmware).
Is your GPU Turing generation or newer?
GPUs older than Turing generation does not have GSP in them, so setting hw.nvidia.registry.EnableGpuFirmware=0 has no effect for these GPUs.

And more. Did your computer sanely suspended on FreeBSD before you upgraded 570.124.04? If not, it would be something in your hardware (including UEFI firmware / BIOS) causing suspend/resume to fail.

For me, after FreeBSD switched from APM to ACPI, never succeeded to suspend/resume (all cases are of ThinkPad series of notebook having nvidia dGPU in them). So I even cannot confirm that status of suspend/resume changes or not. Always fail. This is because I've very surprized finding PR 285741 and PR 285803.
 
T-Aoki said:
Is your GPU Turing generation or newer?
Click to expand...
No, I have recently purchased GTX-1650 after the AMD HD6870 was failing. My old box was quite fine with intel i7-3770 and matching ASUS MOBO. The problem started after addition of new GPU. Probably it was good with earlier diver version 550.*.*, which is not in the repo now. I had to build that from port due to kernel mismatch ( as informed ). This has started with latest 570 from port . The PR PR 285741 is reflection of my actual situation. Only I kept one terminal with root login ready for reboot. I came to know from a old post of SirDice regarding APM_PM. During remaking it was not checked. My be in my case it is the cause. I have to test that. It is good to see now all the related versions are of 1402000 in latest repo.
 
gnath said:
Probably it was good with earlier diver version 550.*.*, which is not in the repo now.
Click to expand...
You can still build, for example, 550.127.05 (previous version on ports tree) or any versions provided by nvidia by overriding version with the same way I've posted another thread. If it also doesn't work, it would be your hardware and/or firmware that is avoiding to suspend/resume just like mine.

Note that if you want nvidia-drm.ko provided by graphics/nvidia-drm-*-kmod, the oldest version supported by current ports is 550.54.14. 550 series is the first branch that is shipped with ashafer@'s DRM codes.
 
T-Aoki said:
GPUs older than Turing generation does not have GSP in them, so setting hw.nvidia.registry.EnableGpuFirmware=0 has no effect for these
Click to expand...
As informed earlier I have GTX-1650 ( last of the series ) and my earlier AMD GPU had no problem. Testing found that setting of hw.nvidia.registry.EnableGpuFirmware=0 has effect some how. It is working as intended.
 
dann said:
The nvidia-modeset module provides foundational display management capabilities for the NVIDIA driver while the nvidia-drm module extends this by integrating with the Linux DRM subsystem, enabling modern graphical features and environments - if you use wayland or graphical KMS features and, if I'm not mistaken, it's loaded automatically if supported.

I would suggest to pay attention to what modules you have loaded with kldstat.
With ONLY linux64 and nvidia OR nvidia-modeset you should have a working X11 session and these modules you can test them with kldload linux64 and kldload nvidia-modeset.

You don't need to set anything in /boot/loader.conf!

Please forgive me for repeating myself.
Click to expand...

It's an old thread, so apologies for the bump, but there's something that I don't understand here:
On FreeBSD 14.2-RELEASE-p3 with drm-61-kmod, if I remove
Code: 
hw.nvidiadrm.modeset=1
from /boot/loader.conf Sway, Hyperland and Labwc won't start: no GPUs found.
What could be the issue?
 
mfoacs said:
It's an old thread, so apologies for the bump, but there's something that I don't understand here:
On FreeBSD 14.2-RELEASE-p3 with drm-61-kmod, if I remove
Code: 
hw.nvidiadrm.modeset=1
from /boot/loader.conf Sway, Hyperland and Labwc won't start: no GPUs found.
What could be the issue?
Click to expand...
The tunable is to actually enable DRM codes in nvidia-drm.ko.
If you're using X11 and have /etc/X11/xorg.conf including needed configurations, it should not matter.

But as you described, I guess you're using Wayland, not X11.
In this case, AFAIK, the tunable SHALL NOT BE REMOVED!
Otherwise, as DRM functionality is not available, Wayland would not be able to find GPU. Never attempt to remove it unless you switch GPUs from nvidia to other manufacturers (Intel, AMD,...) and using Wayland.
 
You must log in or register to reply here.
Back
Top