On 21.10.2016 nvidia released 375.10 as first release in their new beta branch: https://devtalk.nvidia.com/default/topic/972585 It supposedly fixes many efifb related issues and improves recent kernel compatibility: all recent drivers have issues with pcie_port_pm on multi-GPU machines, which is on by default since kernel >= 4.8, c.f. https://devtalk.nvidia.com/default/topic/971733/linux/-370-28-with-kernel-4-8-on-gt-2015-machines-driver-claims-card-not-supported-if-nvidia-is-not-primary-card/
I've been sitting on a new ebuild for days. The problem is basically that nvidia-settings-375.10 wants to include an nvml.h header file which it does not ship, so I could add an ebuild with USE=tools disabled or wait until Nvidia fix their stuff.
(In reply to Jeroen Roovers from comment #1) > nvidia-settings-375.10 wants to include an nvml.h header file which it does > not ship Another (albeit ugly) solution could be to depend on dev-util/nvidia-cuda-toolkit for "tools". dev-util/nvidia-cuda-toolkit ships /opt/cuda/include/nvml.h, so in addition for things to compile, it would need a patching of include paths in nvidia-settings, I guess. But you are absolutely right, it would be best if nvidia just fixes their settings-package...
Better do release the ebuild/bump because nvidia-drivers-370.28 won't build here anymore so it cannot be any worse. * Messages for package x11-drivers/nvidia-drivers-370.28: * Gentoo supports kernels which are supported by NVIDIA * which are limited to the following kernels: * <sys-kernel/gentoo-sources-4.8 * <sys-kernel/vanilla-sources-4.8 * * You are free to utilize epatch_user to provide whatever * support you feel is appropriate, but will not receive * support as a result of those changes. * * Do not file a bug report about this. * * * The following package has failed to build, install, or execute postinst: * * (x11-drivers/nvidia-drivers-370.28:0/370::gentoo, ebuild scheduled for merge), Log file: * '/tmp/portage/x11-drivers/nvidia-drivers-370.28/temp/build.log' with the famous last words: F: fopen_wr S: deny P: nvidia-modeset.mod.d A: /usr/src/linux-4.8.4-gentoo/nvidia-modeset.mod.d R: /usr/src/linux-4.8.4-gentoo/nvidia-modeset.mod.d C: /usr/libexec/gcc/x86_64-pc-linux-gnu/5.4.0/cc1 -E -quiet -nostdinc -I /usr/src/linux-4.8.4-gentoo/arch/x86/include -I ./arch/x86/include/generated/uapi -I ./arch/x86/include/generated -I /usr/src/linux-4.8.4-gentoo/include -I ./include -I /usr/src/linux-4.8.4-gentoo/arch/x86/include/uapi -I /usr/src/linux-4.8.4-gentoo/include/uapi -I ./include/generated/uapi -I /usr/src/linux-4.8.4-gentoo//tmp/portage/x11-drivers/nvidia-drivers-370.28/work/kernel -I /tmp/portage/x11-drivers/nvidia-drivers-370.28/work/kernel -I /tmp/portage/x11-drivers/nvidia-drivers-370.28/work/kernel/common/inc -I /tmp/portage/x11-drivers/nvidia-drivers-370.28/work/kernel -MD nvidia-modeset.mod.d -D __KERNEL__ -D CONFIG_X86_X32_ABI -D CONFIG_AS_CFI=1 -D CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SE * -------------------------------------------------------------------------------- yeah - just like that. I tried to compile it with gcc. 5.4.0 (see above), with 6.2.0 (breaks at some other place), with kernel 4.7.4, 4.8.4 nope. Maybe the problem is because I switched my notebook GPU back from discrete (nvidia-only) to hybrid mode. I'll test that (what happens if I revert it) too, but it's a mess...
(In reply to PetaMem R&D from comment #3) > Better do release the ebuild/bump because nvidia-drivers-370.28 won't build Please take that elsewhere. It's completely unrelated to the 375 series.
(In reply to Oliver Freyermuth from comment #2) > (In reply to Jeroen Roovers from comment #1) > > nvidia-settings-375.10 wants to include an nvml.h header file which it does > > not ship > > Another (albeit ugly) solution could be to depend on > dev-util/nvidia-cuda-toolkit for "tools". > dev-util/nvidia-cuda-toolkit ships /opt/cuda/include/nvml.h, so in addition > for things to compile, it would need a patching of include paths in > nvidia-settings, I guess. > > But you are absolutely right, it would be best if nvidia just fixes their > settings-package... Well, they actually took out some ifdefs that in previous versions of nvidia-settings would prevent it from trying to include nvml.h. So I kind of expect them to ship nvml.h in their next release. Meanwhile I could just use *some* copy of the file and see how that works out.
I installed 375 manually on a 4.8.4 kernel. Now after the installer has run through, of course everything using nvidia OpenGL segfaults :-), but that's a different story. I just want to inform you about some pitfalls during the installation of nvidia-375 Since Kernel 4.7 you can trim unused Kernel symbols. See https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.7-Trim-Unused-KSYMS *Under no circumstances* enable the CONFIG_TRIM_UNUSED_KSYMS option in the kernel if you want to install the external drivers. Naturally, the kernel does not know about the Nvidia drivers to come from an external source (and to need some symbols the kernel itself may not see the need for). So all of the sudden, the nvidia driver sees no VGA Arbiter, no set_cpufreq and about 40 other symbols it needs. ------- The nvidia installer complains about a running X server, although that X-Server runs on a P530 Skylake GPU here. I'm pretty sure it could ignore it altogether, but I was not able to make it ignore that situation. Maybe the package maintainer has more luck. ------- I'm also pretty sure the old version did not complain about a nvidiafb support in the kernel, but the new one does, so you have to disable it.
I was able to install nvidia-drivers with CONFIG_TRIM_UNUSED_KSYMS but my VT disappeared a while ago. Not sure if its related to the the trimming or the bugfixes in this release. Also i am building with the intel drivers (hoping that my system could use my iGPU and nvidia-drivers at the same time at one point in time with vulkan or glvnd) so that would keep some symbols running.
(In reply to Jeroen Roovers from comment #1) > I've been sitting on a new ebuild for days. The problem is basically that > nvidia-settings-375.10 wants to include an nvml.h header file which it does > not ship, so I could add an ebuild with USE=tools disabled or wait until > Nvidia fix their stuff. why is there a nvidia-settings package and the ebuild also installs nvidia-settings? Obviously nvidia-settings is doing some cuda stuff/information so it should depend on the cuda-toolkit i think.
(In reply to Jeroen Roovers from comment #1) > ... I could add an ebuild with USE=tools disabled That would be very nice! ? masked "[-]" , > ... until Nvidia fix their stuff. Thanks a lot!
This: cp "${DISTDIR}"/nvml.h-${PV} "${S}"/nvidia-settings-${PV}/src/ || die should likely be: cp "${DISTDIR}"/nvml.h-${PV} "${S}"/nvidia-settings-${PV}/src/nvml.h || die
Why is this marked as fixed? aplattner from nvidia posted that the fix is included in the *next* release and not backported. However, he posted a link to the git commit that fixes the issue: https://github.com/NVIDIA/nvidia-settings/commit/168e17f53098254b4a5ab93eeb2f23c80ca1d97f.patch
> Why is this marked as fixed? Because - apart from the remaining problem mentioned by Sven B. - the ebuild now downloads the missing nvml.h from your linked commit and adds it before compiling, as you can see in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=853ed85d4ff22ecc6b1cb3cfaa581ba89e3ca068 , which is the commit which closed this issue, thanks to Jeroen Roovers. So yes, downstream the issue is solved (apart from the remaining renaming problem).
(In reply to Sven B. from comment #10) > should likely be: > > cp "${DISTDIR}"/nvml.h-${PV} "${S}"/nvidia-settings-${PV}/src/nvml.h || die Correct. Fixing that.
commit 069898e8c7f9c4bb60b6aa164eba1aa243b02f9e Author: Jeroen Roovers <jer@gentoo.org> Date: Wed Nov 2 16:00:33 2016 +0100 x11-drivers/nvidia-drivers: Copy nvml.h to the right path by Sven B. (bug #597998). Package-Manager: portage-2.3.2
