Please, update 310.xx drivers for Linux 3.7/3.8 compatibility

Thank you.

310.19 drivers are not compatible with these kernels.

A future release should add support for Linux 3.7.

Kernel: 3.7.0-sabayon x86_64 (64 bit) Desktop: Xfce 4.10.0 Distro: Sabayon Linux amd64 10
Machine: Mobo: ASRock model: Z68 Pro3-M Bios: American Megatrends version: P1.40 date: 07/08/2011

GraphicsCard: NVIDIA GF116 [GeForce GTX 550 Ti] X.Org: 1.12.4 driver: nvidia Resolution: 1920x1200@60.0hz
GLX Renderer: GeForce GTX 550 Ti/PCIe/SSE2 GLX Version: 4.3.0 NVIDIA 310.19

No problems with Linux-3.7, all works fine

cu, hf, stephan

I installed 3.8-rc1 kernel, and 313.09 module can not compile. Here is the make.log:

Can someone please create a patch for this to work. :)

No patch needed, the driver compiles without problems.

towo:Defiant> inxi -SG
System:    Host: Defiant Kernel: 3.8.0-rc1.towo.1 x86_64 (64 bit) 
           Desktop: Xfce 4.10.0 Distro: siduction 12.2.0 Riders on the Storm - xfce - (201212092126)
Graphics:  Card: NVIDIA GK107 [GeForce GT 640] X.Org: 1.13.1 driver: nvidia Resolution: 1920x1080@60.0hz 
           GLX Renderer: GeForce GT 640/PCIe/SSE2 GLX Version: 4.3.0 NVIDIA 313.09

Strange. Why it doesn’t compile on my machine then. :(

The stupid rule the world or what?

Have you tried to think for just one second? - beta drivers are compatible with Linux 3.7, the latest stable drivers are not.

Get the patch here.

This patch is for the 304 driver series, not for 310 or above!

He is using beta drivers, so am I. And I have a problem on 3.8-rc1, that he is running without problems.
That patch doesn’t help, I already tried, all the changes are already in beta 313.09.

Here is my kernel config file:

If that can help you guys, to help me solve this problem. :)

Strange, but the patch from birdie post worked. Nvidia 313.09 doesn’t need to be patch for 3.7.x kernel on my machine, but needs to be patched with that patch for 3.8-rc1. That is very strange, because 313.09 does have that patch integrated, but on some other way (in multiple lines, not in one like in the patch).

BTW that patch is for 310.19 drivers.

310.19 doesn’t need this patch, only and 310.14.

Maybe you are right.

Hm, then why didn’t they compile for me without this patch?

Because you use the slh-kernel without a SUBLEVEL?

Vanilla 3.7.0 without any patches. I feel like I applied that NVIDIA patch without realizing it wasn’t necessary any longer ;-)

I am still seeing the problem (or, some problem). Using Linux kernel 3.7.1 (source, from and downloaded from NVidia’s sie 11/26 (and used before, for lessor kernels).

Following my usual pattern, done dozens of times over the years, I first compile the kernel into its own special src and output directories. Then reboot to the “recovery mode” version of that new kernel to compile NVidia. I use a simple script to specify the src and output directories:

$ cat
#!/usr/bin/env sh


export SYSSRC=/home/files/kernels/{KERNAL_SOURCE}/linux-{KERNAL_SOURCE}/
export SYSOUT=/home/files/kernels/${KERNAL_SOURCE}/build64/

sh ./

Worked fine for 3.6.11 and earlier, no change in config for 3.7.1, NVidia goes through a few prompts but quickly acts like it can’t find SYSSRC or SYSOUT.

I am running 64 bit, for kernel and NVidia … could one stream have missed the change?

In 310.19 and 313.09 there are allready some changes in kernel/ to reflect the move of some header files to the uapi directory in 3.7+ kernels.

But there is at least one additional change necessary: Looking into I found:
# Select which Makefile to use based on the version of the
# kernel we are building against: use the kbuild Makefile for
# 2.6 and newer kernels, and the old Makefile for kernels older
# than 2.6.
rm -f Makefile

    if [ -f $HEADERS/$FILE -o -f $OUTPUT/include/$FILE ]; then
        # We are either looking at a configured kernel source
        # tree or at headers shipped for a specific kernel.  
        # Determine the kernel version using a compile check.

This if condition doesn’t reflect the move to uapi if you are depending on the -f $OUTPUT/include/$FILE condition ( probably if you are using a precompiled distribution kernel package).
But I don’t know the right fix for it . Just changing it to
if [ -f $HEADERS/$FILE -o -f $OUTPUT/include/$FILE -o -f $OUTPUT/include/generated/uapi/$FILE ]; then
doesn’t seem to work.
People who have successfully compiled the driver on 3.7+ either are using -f $HEADERS/$FILE condition there ( self compiled kernel ?) or have a workaround in the installed kernel header files ( which is also needed to compile other out of tree modules like the vmware module). Just make a link include/linux -> include/generated/uapi/linux.

Much thanks … both for confirming the issue still exists (for some of us) and confirming I wasn’t going crazy! :)

Not sure why version.h was moved, but see now that is was. Adding symbolic link fixed the problem for me.

It is because when try to compile conftest$$.c file, gcc still do not have linux/version.h in its header look up path. You have to modify CFLAGS too.

Another way I found to solve this problem is using the other configure branch for “2.6 kernel older than 2.6.6” where the script detect version from kernel source Makefile and config. I just hack that branch to work for 3.7 version too. It may not be the right thing to do, but works for me.

here is my patch for