When nvidia-uvm is loaded, "modprobe -r nvidia" does not work since nvidia module is in use by nvidia-uvm module. Therefore the user or the software that tries to unload the module has to learn to do "modprobe -r nvidia-uvm nvidia" instead. Please consider additionally installing /etc/modprobe.d/nvidia-uvm.conf with remove nvidia modprobe -r --ignore-remove nvidia-uvm nvidia or softdep nvidia post: nvidia-uvm to let modprobe transparently handle the dependency. In the latter case, nvidia-uvm will be automatically loaded after nvidia as well. Reproducible: Always
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. ***