Summary: | x11-drivers/nvidia-drivers-334.21-r3 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | bjorn <megaflow> |
Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alex.wabik, amonakov+bugs.gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
bjorn
2014-04-08 04:35:27 UTC
*** This bug has been marked as a duplicate of bug 506168 *** (In reply to Jeroen Roovers from comment #1) > > *** This bug has been marked as a duplicate of bug 506168 *** Hm, it doesn't really look like a duplicate to me. Any comment on why it's closed as such? I guess what happens is that bjorn has some package in boot sequence that tries to load the module and succeeds, now that nvidia-modprobe is suid and available on standart path; but the module cannot initialize the GPU after bbswitch has turned it off. Not many applications try to load the module. It's usually either nvidia-smi, Xorg configured to load the nvidia driver, or CUDA applications. For now the recommendation is to disable auto-start of such applications and start them with "optirun --no-xorg" as needed. I remove bumblebee and xdm from rc-update. And start /etc/init.d/xdm, xorg seem to autoload the nvidia module after i log in on xfce .top is showing upowerd is using 70% %CPU dmesg show this [ 1411.810259] NVRM: The NVIDIA probe routine failed for 1 device(s). [ 1411.810261] NVRM: None of the NVIDIA graphics adapters were initialized! [ 1411.810350] NVRM: NVIDIA init module failed! [ 1411.831985] NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:0dcd) NVRM: installed in this system is not supported by the 334.21 NVRM: NVIDIA Linux driver release. Please see 'Appendix NVRM: A - Supported NVIDIA GPU Products' in this release's NVRM: README, available on the Linux driver download page NVRM: at www.nvidia.com. if i start bumblebee . and run optirun bash. All is normal, but if i exit bash dmesg spam the previous message again. i have build x11-drivers/nvidia-drivers-334.21-r3 with the follow USE flags X acpi multilib tools -pax_kernel -uvm i dont have the problem with x11-drivers/nvidia-drivers-334.21 i also use sys-fs/eudev-1.5.3-r1 i can try the sys-fs/udev package. Or remove acpi from nvidia-drivers You probably didn't have this problem with earlier revision because nvidia-modprobe wasn't available for whatever is loading nvidia driver now. From the symptoms it looks like bbswitch was loaded before loading nvidia; see dmesg to check. If you want to use bumblebee, you will have to find out what is causing the nvidia module to be loaded. looks like udev is loading the module /var/log/Xorg.0.log [ 93.330] (II) config/udev: Adding drm device (/dev/dri/card1) [ 93.330] (II) xfree86: Adding drm device (/dev/dri/card1) [ 93.332] removing GPU device /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1 /dev/dri/card1 but i have blacklist the nvidia module in /etc/modprobe.d/blacklist i downgrade back to x11-drivers/nvidia-drivers-334.21 for now i'm i the only 1 with this problem ? I have the problem too. Everything was fine with nvidia-drivers-334.21 and older. When I updated to nvidia-drivers-334.21-r3, my indicator started to show that nvidia card becomes active in random moments. If I run anything that triggers bbswitch, eg: $ optirun ls then, after the optirun command exits, the nvidia card becomes switched off... until some time passes, 10-15 minutes, when it suddenly powers on again out of nowhere. Please investigate it. I was going to have package.mask on nvidia drivers, but nvidia-drivers-334.21 was removed today, and I do not want to downgrade to older driver. Please ask me for any other additional information. Does the problem go away if you temporarily remove nvidia-modprobe or make it non-suid? If so, can you find out what's triggering it? For instance make nvidia-modprobe a bash script: #!/bin/bash p=$$ while [ $p -ne 1 ]; do tr \\0 \ </proc/$p/cmdline; echo; p=`cut -d\ -f4</proc/$p/stat` done > /tmp/zzz and then 'tail -F /tmp/zzz' and wait until something is there. This is a good idea. I will use such a script for getting some info. Here it comes: $ tail -F /tmp/zzz /bin/bash /usr/bin/nvidia-modprobe /usr/lib64/chromium-browser/chrome --type=plugin --plugin-path=/usr/lib64/nsbrowser/plugins/libflashplayer.so --lang=pl --channel=4943.13.1687998501 chromium-browser --extra-plugin-dir=/usr/lib64/nsbrowser/plugins And this repeats a lot of times. Why would chromium call nvidia-modprobe? And, BTW, when nvidia-modprobe is a script which only logs the process hierarchy, the nvidia card does not power on... but optirun still works! Looks like bumblebee does not use nvidia-modprobe. It's not chromium itself, it's the Flash video player; most likely nVidia VDPAU library triggers (perhaps indirectly, through libnvidia-cfg) nvidia-modprobe. So yeah, nvidia-modprobe is at conflict with Bumblebee's mode of operation. On some hardware, implicitly loading the module and using the card like that won't work after bbswitch turned off the card, as the nvidia kernel module won't be able to bring up the gpu correctly. So this is a bug in the flash plugin? I guess that unless whole plugin process is run in the optirun context (like running whole chromium browser with optirun), it should have absolutely no possibility of doing anything with nvidia drivers.
How this issue should be solved? For me, as I run applications using nvidia only explicitly via optirun, whole nvidia-modprobe script could be deleted.
> So yeah, nvidia-modprobe is at conflict with Bumblebee's mode of operation.
Maybe add USE=bumblebee, which disables nvidia-modprobe in nvidia-drivers, and make bumblebee depend on nvidia-drivers USE=bumblebee, so it's not possible to install bumblebee if nvidia-drivers have no USE=bumblebee?
My problem comes from nvidia-smi . I had a script to probe the temp off my gpu, and the last drivers autoload nvidia.ko but not with the x11-drivers/nvidia-drivers-334.21. although i downgrade to 331.49-r3 because i had hard crashe with te 334.21 series (In reply to Aleksander Wabik from comment #11) > So this is a bug in the flash plugin? I guess that unless whole plugin > process is run in the optirun context (like running whole chromium browser > with optirun), it should have absolutely no possibility of doing anything > with nvidia drivers. No, it's not a bug (and certainly not in the flash player), it's all working as intended: flash plugin loads the vdpau library, vdpau library loads vendor-specific library libvdpau-nvidia.so, which in turn loads libnvidia-cfg.so, which in turn tries to load the module via nvidia-modprobe and succeeds, since nvidia-modprobe is suid (note that I did not verify that each step takes place exactly like that, but it's all plausible). It's just the end result that's not intended on bumblebee-using hardware, where you're supposed to run anything on nvidia with a wrapper that talks to the daemon. One could say it's a bug or a shortcoming in how Bumblebee is designed to work. > How this issue should be solved? For me, as I run applications using nvidia > only explicitly via optirun, whole nvidia-modprobe script could be deleted. "INSTALL_MASK=nvidia-modprobe emerge -1 nvidia-drivers" should do it. For a permanent effect the variable could be set via /etc/portage/package.env. > > So yeah, nvidia-modprobe is at conflict with Bumblebee's mode of operation. > > Maybe add USE=bumblebee, which disables nvidia-modprobe in nvidia-drivers, > and make bumblebee depend on nvidia-drivers USE=bumblebee, so it's not > possible to install bumblebee if nvidia-drivers have no USE=bumblebee? Hm. What would make sense and potentially be desirable to more than just Bumblebee users is to have a USE flag for installing nvidia-modprobe suid (right now it's installed suid unconditionally), and then have bumblebee depend on nvidia-drivers with that flag disabled. People who would want "USE=uvm -suid" would be able to arrange nvidia-uvm.ko loaded automatically with nvidia.ko via modprobe.d softdep. |