Summary: | x11-drivers/nvidia-drivers USE=uvm - adjust modprobe.d for nvidia-uvm | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander Monakov <amonakov+bugs.gentoo> |
Component: | [OLD] Library | Assignee: | Jeroen Roovers (RETIRED) <jer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alex.wabik, megaflow, tante |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/Bumblebee-Project/Bumblebee/issues/565 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Alexander Monakov
2014-03-29 16:15:05 UTC
Fixed in 331.49-r2 and 334.21-r2 by installing an additional script as </etc/modprobe.d/nvidia-uvm.conf>. Thanks for the report! Unfortunately, Bumblebee users who emerge nvidia-drivers with USE=uvm will see a regression in behavior. When posting the bug report, I wasn't aware that Bumblebee was using rmmod rather than "modprobe -r" to unload the nvidia module. Since rmmod does not examine the config files, Bumblebee daemon ends up unable to unload the module, since nvidia-uvm is now loaded always rather than just for CUDA applications. We'll try to roll out a new Bumblebee release soon to resolve the issue. In the meantime, if you're affected please re-emerge nvidia-drivers with USE=-uvm, or use the live ebuild from the bumblebee overlay: sudo EGIT_BRANCH=develop emerge -1 bumblebee-9999 I apologize for the inconvenience. (In reply to Alexander Monakov from comment #2) > Unfortunately, Bumblebee users who emerge nvidia-drivers with USE=uvm will > see a regression in behavior. When posting the bug report, I wasn't aware > that Bumblebee was using rmmod rather than "modprobe -r" to unload the > nvidia module. Since rmmod does not examine the config files, Bumblebee > daemon ends up unable to unload the module, since nvidia-uvm is now loaded > always rather than just for CUDA applications. No, nvidia-uvm.ko is loaded as needed, and gets unloaded prior to attempting to unload nvidia.ko. If nvidia-uvm.ko is still being used, it can't be unloaded, and since the nvidia-uvm.ko could very well be in use by a different user than the X11 user, this is expected behaviour. It should be expected that when nvidia.ko is used for computation (through nvidia-uvm.ko), it's impossible to switch to another driver. Bumblebee should then simply fail gracefully and perhaps try again later. > We'll try to roll out a new Bumblebee release soon to resolve the issue. In > the meantime, if you're affected please re-emerge nvidia-drivers with > USE=-uvm, or use the live ebuild from the bumblebee overlay: So that you then can't use CUDA anymore? It's apparently a choice users will have to make for themselves. (In reply to Jeroen Roovers from comment #3) > (In reply to Alexander Monakov from comment #2) > > Unfortunately, Bumblebee users who emerge nvidia-drivers with USE=uvm will > > see a regression in behavior. When posting the bug report, I wasn't aware > > that Bumblebee was using rmmod rather than "modprobe -r" to unload the > > nvidia module. Since rmmod does not examine the config files, Bumblebee > > daemon ends up unable to unload the module, since nvidia-uvm is now loaded > > always rather than just for CUDA applications. > > No, nvidia-uvm.ko is loaded as needed It was the case before (nvidia-modprobe would load it for CUDA), but now "softdep nvidia post: nvidia-uvm" causes it to be loaded immediately after nvidia. The difference is, previously loading nvidia.ko for, say, OpenGL applications, did not cause nvidia-uvm.ko to be loaded. > , and gets unloaded prior to attempting > to unload nvidia.ko. If nvidia-uvm.ko is still being used, it can't be > unloaded, and since the nvidia-uvm.ko could very well be in use by a > different user than the X11 user, this is expected behaviour. It should be > expected that when nvidia.ko is used for computation (through > nvidia-uvm.ko), it's impossible to switch to another driver. Bumblebee > should then simply fail gracefully and perhaps try again later. > > > We'll try to roll out a new Bumblebee release soon to resolve the issue. In > > the meantime, if you're affected please re-emerge nvidia-drivers with > > USE=-uvm, or use the live ebuild from the bumblebee overlay: > > So that you then can't use CUDA anymore? It's apparently a choice users will > have to make for themselves. That's why I said "or use the live ebuild...": users who want to use CUDA with Bumblebee can use the not-released-yet version; for users who don't need CUDA re-emerging with USE=-uvm is probably simpler. (In reply to Alexander Monakov from comment #4) > > No, nvidia-uvm.ko is loaded as needed > > It was the case before (nvidia-modprobe would load it for CUDA), but now > "softdep nvidia post: nvidia-uvm" causes it to be loaded immediately after > nvidia. The difference is, previously loading nvidia.ko for, say, OpenGL > applications, did not cause nvidia-uvm.ko to be loaded. Loading nvidia-uvm.ko with nvidia.ko is an unintended consequence. I'd be pretty happy to change that to something more appropriate. Also, the patch in question oddly removes -Wall but leaves various other GCC warning flags in place. There is nothing wrong with -Wall and if upstream uses it, then so should we. oops, wrong bug. (In reply to Jeroen Roovers from comment #5) > (In reply to Alexander Monakov from comment #4) > > > No, nvidia-uvm.ko is loaded as needed > > > > It was the case before (nvidia-modprobe would load it for CUDA), but now > > "softdep nvidia post: nvidia-uvm" causes it to be loaded immediately after > > nvidia. The difference is, previously loading nvidia.ko for, say, OpenGL > > applications, did not cause nvidia-uvm.ko to be loaded. > > Loading nvidia-uvm.ko with nvidia.ko is an unintended consequence. I'd be > pretty happy to change that to something more appropriate. As the initial report said, alternatively to "softdep" you can use the "remove" clause, but that needs kmod-14 or newer (currently kmod-16 and kmod-9999 are in tree, so only users who upgrade nvidia-drivers now without upgrading kmod for over a year will see breakage). Was there a particular reason you went with "softdep" earlier? Thanks. (In reply to Alexander Monakov from comment #8) > Was there a particular reason you went with "softdep" earlier? Thanks. No particular reason. I have changed it around in both -r3 ebuilds. *** Bug 507098 has been marked as a duplicate of this bug. *** |