Can't kldload nvidia-drm

T-Aoki said:
Are you sure graphics/drm-61-kmod is rebuilt/reinstalled, too?
  • graphics/nvidia-drm-kmod pulls in graphics/nvidia-drm-61-kmod for 14.3-Release by default,
  • graphics/nvidia-drm-61-kmod depends on both graphics/drm-61-kmod and x11/nvidia-driver.
So if graphics/drm-61-kmod is not updated (as it could be considered to be up-to-date), it causes mis-match.
Click to expand...

Interesting. No, I have just been building graphics/nvidia-drm-kmod. I have not been building graphics/drm-61-kmod (or x11/nvidia-driver). I thought that nvidia-drm-kmod was a meta port that pulled in anything else it needed.

To be super clear, what ports do I need to build?

- graphics/nvidia-drm-kmod
- graphics/drm-61-kmod
- x11/nvidia-driver

All of them? Are there others? Does build order matter?
 
GlenH said:
Interesting. No, I have just been building graphics/nvidia-drm-kmod. I have not been building graphics/drm-61-kmod (or x11/nvidia-driver). I thought that nvidia-drm-kmod was a meta port that pulled in anything else it needed.

To be super clear, what ports do I need to build?

- graphics/nvidia-drm-kmod
- graphics/drm-61-kmod
- x11/nvidia-driver

All of them? Are there others? Does build order matter?
Click to expand...
No need to rebuild graphics/nvidia-drm-kmod. This is the metaport to check OS version to determine which variant to pull in and install AT THE FIRST TIME. Instead, you need graphics/nvidia-drm-61-kmod to be rebuilt.

The build order wouldn't matter, and you need to restart when ALL of
  • x11/nvidia-driver
  • graphics/drm-61-kmod
  • graphics/nvidia-drm-61-kmod
are rebuilt/reinstalled sanely. Don't restart in the middle of the simultaneous operations.
 
T-Aoki said:
No need to rebuild graphics/nvidia-drm-kmod. This is the metaport to check OS version to determine which variant to pull in and install AT THE FIRST TIME. Instead, you need graphics/nvidia-drm-61-kmod to be rebuilt.

The build order wouldn't matter, and you need to restart when ALL of
  • x11/nvidia-driver
  • graphics/drm-61-kmod
  • graphics/nvidia-drm-61-kmod
are rebuilt/reinstalled sanely. Don't restart in the middle of the simultaneous operations.
Click to expand...

OK. It is midnight where I am. I will try this tomorrow. Thanks for the help.
 
first of all, thanks to T-Aoki for a lot of information!

DISCLAMER: At least at the moment Hyprland shows me black screen ( even though my keyboard does no longer respond to any key presses ) - this wasn't even the case before. I hope that this code helps someone to dig deeper or even find why this fails. I like the idea of running wayland instead of x11 ( and I enjoyed it on 14.2 ), but the general lack of knowledge of mine makes me think I will have to go back to x11 unless I manage to resolve this all by the end of Sunday.

the attached script (build-hyprland-nvidia.txt) "prepares" the system for Hyprland. it's contents is based on the discussions in this thread ( as far as I have understood it ). I ran it locally w/o errors.

the following is my hypr.zsh script that should start Hyprland after the build-hyprland-nvidia.txt.

sh: 
#!/usr/bin/env zsh

rm -rf $XDG_RUNTIME_DIR/*

# ERR_LOG=~/.hyprland.err
# OUT_LOG=~/.hyprland.out
# CONFIG=~/.config/hypr/hyprland.conf

export HYPRLAND_LOG_FILE="$HOME/hyprland.log"
export HYPRLAND_CONFIG="$HOME/.config/hypr/hyprland.conf"

export LIBSEAT_BACKEND=seatd
export SEATD_SOCK=/var/run/seatd.sock

export XDG_CURRENT_DESKTOP=Hyprland
export XDG_SESSION_TYPE=wayland
export XDG_SESSION_DESKTOP=Hyprland
export WAYLAND_DESKTOP=wayland-1
export MOZ_ENABLE_WAYLAND=1
export WLR_NO_HARDWARE_CURSORS=1
export XKB_DEFAULT_RULES=evdev
export GDK_BACKEND=wayland
export QT_QPA_PLATFORM=wayland
export QT_QPA_PLATFORMTHEME="qt5ct"
export QT_WAYLAND_DISABLE_WINDOWDECORATION=1
export SDL_VIDEODRIVER=wayland
export WM=Hyprland
export CLUTTER_BACKEND=wayland
export BEMENU_BACKEND=wayland


exec dbus-run-session Hyprland
 

Attachments

What happenes if you replace exec dbus-run-session Hyprland to exec dbus-launch --exit-with-session ck-launch-session Hyprland?
And are there some error messages shown on vty console?
 
Oh, forgot to ask what I should have asked at the first place (possibly overlooked, though).
Are your users starting Wayland (here, hyprland compositor?) belong to video group?

For use with nvidia-modeset.ko (or older version that don't have it, nvidia.ko) but without nvidia-drm.ko, IIRC, it uses old-school "user mode settings", thus, don't need it. But for nvidia-drm.ko, it uses KMS (kernel mode settings) that requires some priviledge and belonging to video group gives it.
 
T-Aoki said:
Oh, forgot to ask what I should have asked at the first place (possibly overlooked, though).
Are your users starting Wayland (here, hyprland compositor?) belong to video group?

For use with nvidia-modeset.ko (or older version that don't have it, nvidia.ko) but without nvidia-drm.ko, IIRC, it uses old-school "user mode settings", thus, don't need it. But for nvidia-drm.ko, it uses KMS (kernel mode settings) that requires some priviledge and belonging to video group gives it.
Click to expand...
good morning T-Aoki , the user who starts wayland is in the video group:



dmitry@t640 ~ $ id
uid=1001(dmitry) gid=1001(dmitry) groups=1001(dmitry),0(wheel),44(video)
 
Does /dev/dri/card0 (the number could vary if multiple cards including iGPU are detected, though) and /dev/dri/renderD128, both of which are symlinks to /dev/drm/0 and /dev/drm/128 respectively?

These should be created when nvidia-drm.ko (and/or any other DRM driver like i915kms.ko and amdgpu.ko) is sanely recognized as DRM/KMS driver and start working. If any of rebuilds/reinstalls went wrong and mis-matches happen, these wouldn't be generated.
 
T-Aoki said:
What happenes if you replace exec dbus-run-session Hyprland to exec dbus-launch --exit-with-session ck-launch-session Hyprland?
And are there some error messages shown on vty console?
Click to expand...
just tried it. no errors at all.

/var/log/messages
Aug 3 12:56:51 t640 seatd[3287]: 00:02:42.227 [INFO] [seatd/server.c:146] New client connected (pid: 3507, uid: 1001, gid: 1001)
Aug 3 12:56:51 t640 seatd[3287]: 00:02:42.227 [INFO] [seatd/seat.c:239] Added client 1 to seat0
Aug 3 12:56:51 t640 seatd[3287]: 00:02:42.227 [INFO] [seatd/seat.c:563] Opened client 1 on seat0


killing -9 brings me to this state:



dmitry@t640 ~ $ ps aux | grep Hyprland
dmitry 3507 0.0 0.1 595452 394500 v0- D 12:56 0:01.22 Hyprland
 
T-Aoki said:
Does /dev/dri/card0 (the number could vary if multiple cards including iGPU are detected, though) and /dev/dri/renderD128, both of which are symlinks to /dev/drm/0 and /dev/drm/128 respectively?

These should be created when nvidia-drm.ko (and/or any other DRM driver like i915kms.ko and amdgpu.ko) is sanely recognized as DRM/KMS driver and start working. If any of rebuilds/reinstalls went wrong and mis-matches happen, these wouldn't be generated.
Click to expand...

looks like the card is detected:



dmitry@t640 ~ $ ls -lv /dev/dri/card0
lrwxr-xr-x 1 root wheel 8 Aug 3 14:53 /dev/dri/card0 -> ../drm/0

dmitry@t640 ~ $ ls -lv /dev/dri/renderD128
lrwxr-xr-x 1 root wheel 10 Aug 3 14:53 /dev/dri/renderD128 -> ../drm/128

dmitry@t640 ~ $ ls -lv /dev/drm/0
crw-rw---- 1 root video 0x88 Aug 3 14:53 /dev/drm/0

dmitry@t640 ~ $ ls -lv /dev/drm/128
crw-rw---- 1 root video 0x168 Aug 3 14:53 /dev/drm/128
 
dmitry n medvedev said:
T-Aoki, the only way to unfreeze the system is to do this:



dmitry@t640 ~ $ doas service seatd restart
Stopping seatd.
Waiting for PIDS: 3288.
Starting seatd.
Click to expand...
Hmmmm... Problem in interaction between hyprland and seatd? Not sure.
I myseld never tried hyprland.

Another point that can affect.
Are there anything in your /usr/local/lib/compat/pkg/?
This directory is created as a place to keep old versions of libraries in ancient days and still alive.

If it's not empty and containing something related with nvidia drivers and/or hyprland (including its dependencies), there's possibility that libraries there are picked instead of correct ones.

If this seems to be the case, try moving the directory somewhere else (or renaming it). Actually deleting it without confirmation is a bad idea, as it can cause something to stop working. Try and error would be needed.

TBH, IIRC, when /usr/local/lib/compat/pkg is first introduced by portupgrade, it was always the last place to be searched for. But afterwards the situations are significantly changed.
 
T-Aoki said:
Hmmmm... Problem in interaction between hyprland and seatd? Not sure.
I myseld never tried hyprland.

Another point that can affect.
Are there anything in your /usr/local/lib/compat/pkg/?
This directory is created as a place to keep old versions of libraries in ancient days and still alive.

If it's not empty and containing something related with nvidia drivers and/or hyprland (including its dependencies), there's possibility that libraries there are picked instead of correct ones.

If this seems to be the case, try moving the directory somewhere else (or renaming it). Actually deleting it without confirmation is a bad idea, as it can cause something to stop working. Try and error would be needed.

TBH, IIRC, when /usr/local/lib/compat/pkg is first introduced by portupgrade, it was always the last place to be searched for. But afterwards the situations are significantly changed.
Click to expand...



dmitry@t640 ~ $ ls -la /usr/local/lib/compat/pkg
total 1
drwxr-xr-x 2 root wheel 2 Jul 29 19:16 .
drwxr-xr-x 3 root wheel 3 Jul 29 19:16 ..
 
T-Aoki , some more info to think over:




dmitry@t640 ~ $ doas procstat -k 3617
PID TID COMM TDNAME KSTACK
3617 103004 Hyprland - mi_switch _vm_page_busy_sleep vm_page_busy_acquire lkpi_vmf_insert_pfn_prot_locked __nv_drm_gem_nvkms_handle_vma_fault linux_cdev_pager_populate vm_fault_allocate vm_fault vm_fault_trap trap_pfault trap calltrap
3617 103400 Hyprland - mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kqueue_scan kqueue_kevent kern_kevent_fp kern_kevent_generic sys_kevent amd64_syscall fast_syscall_common
3617 103401 Hyprland - mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll_kfds kern_poll sys_poll amd64_syscall fast_syscall_common
3617 103402 Hyprland - mi_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait kern_poll_kfds kern_poll sys_poll amd64_syscall fast_syscall_common
3617 103405 Hyprland [pango] fontcon mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private sys__umtx_op amd64_syscall fast_syscall_common
 
I had problems with Hyprland, too. In general it seems to me that Wayland compositors with Nvidia driver are a hit and miss.
Have you tried Wayfire just to check Wayland in general? Wayfire seems to work rather good with Nvidia.
 
OK, I was hopeful, but this didn't work.

The behavior is almost but not exactly the same. X11 still works, and now if I start and stop the X server, the console seems fine. But if I try to start plasma6 I still get a black screen, and if I control-F3 to a console, it's screwed up in the same way.

Wayfire won't launch, but now it returns a segmentation fault at seatd/seat.c line 240
 
GlenH said:
OK, I was hopeful, but this didn't work.

The behavior is almost but not exactly the same. X11 still works, and now if I start and stop the X server, the console seems fine. But if I try to start plasma6 I still get a black screen, and if I control-F3 to a console, it's screwed up in the same way.

Wayfire won't launch, but now it returns a segmentation fault at seatd/seat.c line 240
Click to expand...
well... it starts looking to me that no graphics could be used in freeBSD 14.3 via NVIDIA card(s). how are other people doing? I mean, it cannot be true that it is only me who has nvidia.
 
dmitry n medvedev said:
well... it starts looking to me that no graphics could be used in freeBSD 14.3 via NVIDIA card(s). how are other people doing? I mean, it cannot be true that it is only me who has nvidia.
Click to expand...
I have a Nvidia card on 14.3 For me X is fine, Wayland is a hit and miss, some compositors work sometimes other work at other times - not really stable.
 
T-Aoki said:
Hmmmm... Problem in interaction between hyprland and seatd? Not sure.
I myseld never tried hyprland.

Another point that can affect.
Are there anything in your /usr/local/lib/compat/pkg/?
This directory is created as a place to keep old versions of libraries in ancient days and still alive.

If it's not empty and containing something related with nvidia drivers and/or hyprland (including its dependencies), there's possibility that libraries there are picked instead of correct ones.

If this seems to be the case, try moving the directory somewhere else (or renaming it). Actually deleting it without confirmation is a bad idea, as it can cause something to stop working. Try and error would be needed.

TBH, IIRC, when /usr/local/lib/compat/pkg is first introduced by portupgrade, it was always the last place to be searched for. But afterwards the situations are significantly changed.
Click to expand...

"Are there anything in your /usr/local/lib/compat/pkg/?"

Mine is empty.

"Are your users starting Wayland (here, hyprland compositor?) belong to video group?"

% id
uid=1001(glen) gid=1001(glen) groups=1001(glen),0(wheel),5(operator),44(video)
Click to expand...

"Does /dev/dri/card0 (the number could vary if multiple cards including iGPU are detected, though) and /dev/dri/renderD128, both of which are symlinks to /dev/drm/0 and /dev/drm/128 respectively?"

In my case, no:

# ls -lv /dev/dri/card0
ls: /dev/dri/card0: No such file or directory
# ls -lv /dev/dri/renderD128
ls: /dev/dri/renderD128: No such file or directory
# ls -lv /dev/drm/0
ls: /dev/drm/0: No such file or directory
# ls -lv /dev/drm/128
ls: /dev/drm/128: No such file or directory
Click to expand...

What's the solution to this?
 
You must log in or register to reply here.
Back
Top