Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 506168 - x11-drivers/nvidia-drivers USE=uvm - adjust modprobe.d for nvidia-uvm
Summary: x11-drivers/nvidia-drivers USE=uvm - adjust modprobe.d for nvidia-uvm
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Jeroen Roovers
URL:
Whiteboard:
Keywords:
: 507098 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-03-29 16:15 UTC by Alexander Monakov
Modified: 2014-05-21 22:05 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Monakov 2014-03-29 16:15:05 UTC
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
Comment 1 Jeroen Roovers gentoo-dev 2014-03-29 16:50:00 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!
Comment 2 Alexander Monakov 2014-03-31 16:22:16 UTC
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.
Comment 3 Jeroen Roovers gentoo-dev 2014-03-31 18:09:04 UTC
(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.
Comment 4 Alexander Monakov 2014-03-31 18:30:33 UTC
(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.
Comment 5 Jeroen Roovers gentoo-dev 2014-03-31 19:01:37 UTC
(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.
Comment 6 Jeroen Roovers gentoo-dev 2014-03-31 19:43:57 UTC
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.
Comment 7 Jeroen Roovers gentoo-dev 2014-03-31 19:44:06 UTC
oops, wrong bug.
Comment 8 Alexander Monakov 2014-03-31 20:13:17 UTC
(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.
Comment 9 Jeroen Roovers gentoo-dev 2014-03-31 20:24:39 UTC
(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.
Comment 10 Jeroen Roovers gentoo-dev 2014-04-08 12:51:07 UTC
*** Bug 507098 has been marked as a duplicate of this bug. ***