today i found out that I couldn't access smb file shares on my laptop that has a secondary nvidia gpu. i am using the cursèd drivers
any time I tried to navigate to one in kde dolphin, i'd get a notification saying that the kio worker had crashed. who was in the call stack? libnvidia-tls
the workaround? set this environment variable in ~/.config/environment.d/: __GL_CONSTANT_FRAME_RATE_HINT=3
truly the way it's meant to be played :imcold:
i'm... not entirely sure if i want to know why that's what fixes it
I don't even *really* know what it does lol.
wh-
o.o
other than that it's been mostly pretty good. if i want to play a game using the gpu i have to start it with these environment variables
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia
i ended up just installing lutris so i wouldn't have as much stuff to juggle
on fedora, `akmod` builds the nvidia kernel model in the background *after* the rpm transaction finishes.
so on this page there are a bunch of warnings to wait for that to happen: https://rpmfusion.org/Howto/NVIDIA#Current_GeForce.2FQuadro.2FTesla
however, a really easy way to end up not waiting is if you use the Discover gui to update packages and click the checkbox to automatically reboot after. then you won't be able to boot because you won't have a nvidia kernel module.
edit 2025/05/03: i was wrong about that! see this reply (https://f9.hell-labs.net/index.php?msg=224) instead of reading the rest of this post (◕ˉ◕✿)
to recover from that state you have to boot an old kernel, build the module for the kernel that is missing it, and then boot the new kernel.
the way to check if the module has been built for a kernel:
# in this case, it is present so the version number is printed
$ modinfo -F version nvidia -k 6.13.9-200.fc41.x86_64
570.133.07
# in this case it's missing so an error is printed
$ modinfo -F version nvidia -k 6.13.10-200.fc41.x86_64
modinfo: ERROR: Module nvidia not found.
to find which kernel versions are installed,
$ dnf list kernel
Updating and loading repositories:
Repositories loaded.
Installed packages
kernel.x86_64 6.11.4-301.fc41 anaconda
kernel.x86_64 6.13.9-200.fc41 <unknown>
kernel.x86_64 6.13.10-200.fc41 <unknown>
Available packages
kernel.x86_64 6.13.11-200.fc41 updates
note that the version numbers shown by dnf do not include the machine architecture (x86_64) - modinfo needs the architecture to be specified or it will just report the module as missing
# this doesn't work, .x86_64 is missing at the end
$ modinfo -F version nvidia -k 6.13.9-200.fc41
modinfo: ERROR: Module nvidia not found.
# this works
$ modinfo -F version nvidia -k 6.13.9-200.fc41.x86_64
570.133.07
if you want to manually request building the nvidia module for a specific kernel:
$ sudo akmods --kernels 6.13.10-200.fc41.x86_64
Checking kmods exist for 6.13.10-200.fc41.x86_64 [ OK ]
Building and installing nvidia-kmod [ OK ]
it might take a little while. (on my intel core ultra 7 155h, it took 1 minute and 9 seconds)
afterward i confirmed that it built:
modinfo -F version nvidia -k 6.13.10-200.fc41.x86_64
570.133.07
wow, making akmod be a background task that keeps going after the update transaction seems like a huge mistake on their part... i could swear it wasn't like that in the late aughts but i haven't used proprietary gpu drivers and fedora at the same time since back then
it's a good thing I wrote all that down because I needed that akmod again today after taking a system update through discover
Quote from: lifning on Apr 16, 2025, 07:34 PMwow, making akmod be a background task that keeps going after the update transaction seems like a huge mistake on their part... i could swear it wasn't like that in the late aughts but i haven't used proprietary gpu drivers and fedora at the same time since back then
I'm pretty sure
dkms on Fedora builds modules synchronously during an upgrade, but presumably akmods never do that because they stick the built module in a package and then install
that, and thus can't run at the same time as the RPM transaction that upgraded the kernel or akmod package. (Yes, you could decouple the two steps, but...)
The Plasma UI encouraging automatic reboots after upgrading (as well as fully-offline upgrades which would also reboot immediately after) is a hell of a way to set off that particular footgun ._.
(I used the nvidia akmod package for a time, but I think we swapped the GTX 970(?) for an AMD RX 580 before I ever did a major version upgrade on that system...)
hey so I learned today I was wrong about the akmod thing!
when booting after a new kernel is installed, my laptop would sit at a black screen with a flashing prompt, and the fans would spin up. i assumed this meant it was unrecoverably dead (because in my experience, that's usually what that means!) but during that time it's actually *synchronously building the missing kernel module*. so all i had to do was wait!
this page (https://rpmfusion.org/Howto/NVIDIA) which is like, the canonical source for "how to use nvidia gpus on fedora" doesn't mention that at all 🙃
...the fact that it doesn't output anything to indicate that that's what's happening is a little absurd
it's not exactly related but I need to write this down *somewhere*. i was having an issue with pipewire where whenever i'd launch steam games on my thinkpad p14s gen 5 (intel), audio playback would be totally blocked until i closed them.
tangent
a workaround I used previously was to just use pulseaudio. unfortunately this fell apart as soon as I wanted to play a game *and* capture its video and audio in obs, i'm on wayland and afaik *need* pipewire for that to be possible. whee!
i found that removing the connections between the game and the output device in qpwgraph and putting them back would restore audio (for the game and everything else!), but if basically anything happened that added or removed a connection to the output device (say, a notification sound being played, or opening the volume control plasma widget) it would break again until I re-added the connections.
i eventually stumbled on this: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/618
Quote from: Wim Taymans on gitlab.freedesktop.orgTry setting api.alsa.headroom = 1024 in /etc/pipewire/media-session.d/alsa-monitor.conf
that ended up fixing it, but I had to figure out how to adapt it to wireplumber. here's what I ended up with:
# ALSA node property overrides
# docs: https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/alsa.html
# to reload,
# systemctl --user --now restart wireplumber
monitor.alsa.rules = [
{
matches = [
{
node.name = "~alsa_output.pci.*HiFi__HDMI1__sink"
}
]
actions = {
update-props = {
node.description = "HDMI1 Out" # less verbose
api.alsa.period-size = 1024
api.alsa.headroom = 256 # introduces latency for badly behaved drivers; 256 seems to work, 2048 may be a decent option idk
}
}
}
]
what that setting actually does (reference (https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/alsa.html)):
Quote from: pipewire docsapi.alsa.headroom
This adds extra delay between the hardware pointers and software pointers. In most cases this can be set to 0. For very bad devices or emulated devices (like in a VM) it might be necessary to increase the headroom value.
Type:
integer (samples)
i need to start collecting notes like this somewhere. like a "web site"