Hi folks, I was a little bored, and so I decided to install a newer kernel. I headed over to the always excellent James’ pages https://forums.opensuse.org/blogs/jdmcdaniel3/ and read what he had to say on the matter, particularly on using the stable kernel repo. I followed the instructions there, as follows:
Checked I have installed, via YAST the patterns:
[size=2]
[/size]
Then I did this:
All went according to plan. So then to boot my new kernel, and install the nvidia driver against it. Boot to console/runlevel 3 and run the nvidia driver script as usual.
But this threw the following errors:
cat /var/log/nvidia-installer.log
nvidia-installer log file '/var/log/nvidia-installer.log'
creation time: Fri Sep 13 01:53:04 2013
installer version: 304.88
PATH: /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin
nvidia-installer command line:
./nvidia-installer
-K
-a
Using: nvidia-installer ncurses user interface
-> License accepted by command line option.
-> Installing NVIDIA driver version 304.88.
-> Performing CC sanity check with CC="cc".
-> Performing CC version check with CC="cc".
ERROR: Neither the '/usr/src/linux/include/linux/version.h' nor the '/usr/src/linux/include/generated/uapi/linux/version.h' kernel header file exists. The most likely reason for this is that the kernel source files in '/usr/src/linux' have not been configured.
And now I am (as usual) slightly confused.
Looking at the YAST repositories page, I see that the devel files don’t match the new kernel, but rather are aligned with the old one. Is this correct, or a mix-up at the repo? http://wstaw.org/m/2013/09/13/plasma-desktopCB5084.png
Have I just, with typical bad luck found the repo in a transitional state?
Do the newer kernels not compile against slightly older nvidia drivers? (I have to use 304.88, as my GPU is no longer supported by the new 325.15 driver.)
Just as an afterthought, and while I am in a thread re kernels and YAST etc, at the bottom of that repo page I noticed a package for AMD CPU’s Would this do anything for my set-up? (specs in sig)
Well, you only told zypper to install “kernel-desktop” from the Kernel:Stable repo.
And since the old kernel still is installed (because of the multiversion feature), there was no dependency error either.
So you have to explicitely install the devel packages for the new kernel as well, kernel-desktop-devel should suffice, the rest should happen automatically then.
Click on the Versions tab in YaST (right-bottom), there you can explicitely install/uninstall specific versions.
Or use “zypper in --from Kernel:Stable kernel-desktop-devel” or “zypper in kernel-desktop-devel-3.11.0”.
True, I just tried that search on the uk site and get the same results.
And when I search for a driver for “GeForce 6 series” (you can’t select a specific model there) on the german site, I even get the 325.xx driver as result, although that doesn’t support the GeForce 6 series…:sarcastic:
Well, can’t help you with that, sorry…
But up to now I always clicked on “Unix Drivers” link on the “Download Drivers” page (Drivers - Download NVIDIA Drivers). There the 304.108 is listed.
I’ve got the NVIDIA driver compiled on this kernel, this after a lot of searching, but this is on a bumblebee config. I expect this to work on a NVIDIA only box too.
If you’re interested I can write up the steps I had to take, though IMHO NVIDIA should provide new (beta) drivers that do support the new kernel.
On 09/13/2013 09:16 AM, Knurpht wrote:
>
> I’ve got the NVIDIA driver compiled on this kernel, this after a lot of
> searching, but this is on a bumblebee config. I expect this to work on a
> NVIDIA only box too.
> If you’re interested I can write up the steps I had to take, though IMHO
> NVIDIA should provide new (beta) drivers that do support the new kernel.
And nVidia should submit their kernel code to be part of the kernel, but they
refuse to do so. They are always slow to implement the newest API changes in the
kernel, as is the case with VMware. Of the usual out-of-kernel suppliers, only
VirtualBox gets the changes into the code in a timely manner - usually by rc2 or
rc3 of the kernel development cycle. The difference is that they accept and
incorporate the patches proposed by their users.
>
> Thank you Wolfi! I’ll get on that later. It is curious IMHO that
the
> driver you suggest is not found using nVidia’s website search…
>
> ‘NVIDIA Driver Downloads - Advanced Search’
> (http://www.nvidia.co.uk/Download/Find.aspx?lang=en-uk)
>
> [image: http://wstaw.org/m/2013/09/13/plasma-desktopDr5084.png]
>
> But I have it now via the link you provide in your other
thread…it
> is here for anyone else who is looking:
> ‘Unix Drivers | NVIDIA’ (http://www.nvidia.com/object/unix.html)
>
I now have the 325-15 driver working on both 12.3 and 13.1. Both
required the patch before they would compile using the hardway. I am
sending this from my 12.3 system.
On 09/13/2013 10:33 AM, Carlos E. R. wrote:
> On 2013-09-13 17:04, Larry Finger wrote:
>
>> And nVidia should submit their kernel code to be part of the kernel, but
>> they refuse to do so.
>
> It is not that simple. They can’t.
On 2013-09-13 19:46, gogalthorp wrote:
>
> IP. There are patented things in there is my guess
On one side, Nvidia has patented things, although that’s no obstacle
since the kernel code they publish.
It is the kernel license itself which is the obstacle: they say that the
NVidia kernel modules break their license. They will never accept those
modules inside, that’s why they are externally provided.
It might be even possible that the kernel people continuously modify the
interface so that the proprietary modules stop working. This is a
completely wild, unsupported, and “nasty” guess on my part, which I hope
is false.
As for the driver itself it is proprietary. I heard time ago that many
manufacturers are forced to do closed source drivers because they don’t
own all the licenses for the technologies they use. Besides that,
publishing that code would open doors to their competitors.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
And applied the patch. But it threw a seg fault error:
stephen 20:38:~/bin/nvidia/NVIDIA-Linux-x86_64-304.108>
patch -pl < /home/stephen/bin/nvidia/nvidia-3.11.patch
patch: **** strip count l is not a number
Segmentation fault
I tried it just for lols but needless to say it failed to compile!
Hmmm I have never patched anything other than an old pair of Levi’s before…
I looked at some info pages on patch and guessed that the command should be:
>
> Hmmm I have never patched anything other than an old pair of
Levi’s
> before…
> I looked at some info pages on patch and guessed that the command
> should be:
>
> Code:
> --------------------
> patch -p1 < /home/stephen/bin/nvidia/nvidia-3.11.patch
> --------------------
>
>
> But it still did not work…
>
>
> Code:
> --------------------
> stephen 20:39:~/bin/nvidia/NVIDIA-Linux-x86_64-304.108>
> patch -p1 < /home/stephen/bin/nvidia/nvidia-3.11.patch
> patching file kernel/nv-linux.h
> Hunk #1 FAILED at 957.
> 1 out of 1 hunk FAILED – saving rejects to file
> kernel/nv-linux.h.rej
>
> --------------------
>
>
> And
>
> Code:
> --------------------
> cat ./kernel/nv-linux.h.rej
> — kernel/nv-linux.h
> +++ kernel/nv-linux.h
> @@ -957,7 +957,11 @@
> #endif
>
> #if !defined(NV_VMWARE)
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 11, 0)
> +#define NV_NUM_PHYSPAGES get_num_physpages()
> +#else
> #define NV_NUM_PHYSPAGES num_physpages
> +#endif
> #define NV_GET_CURRENT_PROCESS() current->tgid
> #define NV_IN_ATOMIC() in_atomic()
> #define NV_LOCAL_BH_DISABLE() local_bh_disable()
>
> --------------------
>
>
> Did my first attempt change the original? I will try with a fresh
> copy…
> … >:(… Same result.
>
Are you trying to run the patch against the .run file. I found out
several days ago you have to extract the file firts
Code
NVIDIA-Linux-x86_64-325.15.run -x
Then run the patch against the extracted folder/subfold kernel. Once
I was provided the procedure, I ran it on 12.3 and 13.1 and both
work.
You copy/pasted the text from that page?
Don’t do that, that will result in a mess most of the time!
Just right click on “Raw” on the link you posted, and choose “Save Link as” from the context menu, that should result in a working patch file.
stephen 20:38:~/bin/nvidia/NVIDIA-Linux-x86_64-304.108>
patch -pl < /home/stephen/bin/nvidia/nvidia-3.11.patch
patch: **** strip count l is not a number
Segmentation fault
[/QUOTE]
As you found out already: that’s a digit ‘1’ not a letter ‘l’ in that -p option to patch…
still mystified.