I skipped kernel 2.6.39.rc1 and just tried to compile kernel 2.6.39-rc2, but it has failed to compile twice so far with Exit code 2. Has anyone else looked at or tried to use the next kernel 2.6.39 so far?
Thank You,
On 04/09/2011 09:06 AM, jdmcdaniel3 wrote:
>
> I skipped kernel 2.6.39.rc1 and just tried to compile kernel 2.6.39-rc2,
> but it has failed to compile twice so far with Exit code 2. Has anyone
> else looked at or tried to use the next kernel 2.6.39 so far?
Yes. I have been running both 2.6.39-rc1 and -rc2.
Note, exit code 2 only says that make found an error. As such, that conveys no
information. You need to go back through the console output and find the place
that gcc found an error and report that.
Looking through the capture file I found this information:
In file included from drivers/staging/keucr/smilecc.c:6:0:
drivers/staging/keucr/smcommon.h:9:0: warning: "SUCCESS" redefined
include/scsi/scsi.h:463:0: note: this is the location of the previous definition
CC [M] drivers/usb/image/microtek.o
CC [M] drivers/staging/iio/adc/max1363_ring.o
drivers/staging/hv/hv_mouse.c: In function ‘ReleaseInputDevice’:
drivers/staging/hv/hv_mouse.c:293:3: error: implicit declaration of function ‘udelay’
make[3]: *** [drivers/staging/hv/hv_mouse.o] Error 1
make[2]: *** [drivers/staging/hv] Error 2
make[2]: *** Waiting for unfinished jobs....
This was the only thing that said Error 2 in it.
Thank You,
Hi
That would be the same error here;
https://patchwork.kernel.org/patch/18485/
Looks like someone forgot to include delay.h (or it’s alternative in the newer kernel).
So it indicates this is the Patch:
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index 96934f0..791501d 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -15,6 +15,7 @@
#include <linux/uaccess.h>
#include <linux/module.h>
#include <linux/ctype.h>
+#include <linux/delay.h>
#include "trace_output.h"
Just how would one implement this patch to the kernel 2.6.39.rc2? Obviously I can just wait for kernel 2.6.39-rc3 to come out.
Thank You,
Hi
If linux/delay.h is there, you would need to check in /include/linux/ all you need to do as a quick hack is edit drivers/staging/hv/hv_mouse.c to add the line. Then recompile. If it works, make a patch and submit it to kernel.org.
So from all of this I was able to put together the following actions:
- You found a kernel 2.6.39-rc2 problem report on drivers/staging/hv/hv_mouse.o file I was having problems with.
- The report suggested an issue with delay.h. I checked in the folder include/linux/ and found the file delay.h
- So then I modified the file drivers/staging/hv/hv_mouse.c to add the line **#include <linux/delay.h>
**4. Since I am using SAKC, I had to put a pause in, before the file was compile to modify the hv_mouse.c text file to add in the line. - The Kernel File 2.6.39-rc2 then compiled properly.
So, with your help, I was able to fix the issue. I am not sure I understand the proper procedure for this fix nor just what I report as a bug or what I would submit as a fix. It is not clear to me if everyone or just who would see this error. Can someone compile this kernel OK due to having different hardware or if not, why would some say it compiled OK for them? Just a few more questions for being so smart.
Thank You,
Hi
Different compile flags would possibly be the reason.
Looks like it’s already been discussed here;
Re: [PATCH]drivers:staging:hv:hv_mouse.c Fix build error in hv_mouse. | Linux | Kernel
On 04/09/2011 01:36 PM, malcolmlewis wrote:
>
> Hi
> Different compile flags would possibly be the reason.
>
> Looks like it’s already been discussed here;
> ‘Re: [PATCH]drivers:staging:hv:hv_mouse.c Fix build error in hv_mouse.
> | Linux | Kernel’
> (http://www.gossamer-threads.com/lists/linux/kernel/1363198)
The most likely explanation is that some systems or architectures are including
delay.h in a manner that other systems do not. That way, it compiles for some
people and not for others. This kind of thing slips through. I recently missed
an include for a wireless driver. The code would compile for i386 and x86_64
architectures, but fail for ARM and PPC.
FWIW, the fix for this problem went into the mainline kernel on Wed., April 6 as
commit 7e3bf1d3308934bc1b8ca492f47. It will be part of 2.6.39-rc3 and is already
part of 2.6.39-rc2-gitX.
Well, the new kernel 2.6.39-rc2 does load, but none of my NVIDIA drivers will load any more including 260.19.44 or 270.30 so I guess I will be waiting for a new Video driver version as well. I will give it another shot when kernel 2.6.39-rc3 hits the streets.
Thank You,
On 04/09/2011 04:06 PM, jdmcdaniel3 wrote:
>
> Well, the new kernel 2.6.39-rc2 does load, but none of my NVIDIA drivers
> will load any more including 260.19.44 or 270.30 so I guess I will be
> waiting for a new Video driver version as well. I will give it another
> shot when kernel 2.6.39-rc3 hits the streets.
The problem is that the nVidia driver uses the Big Kernel Lock. The BKL was
introduced when Simultaneous MultiProcessing code was introduced and was a quick
hack to get SMP running. It has a major problem in that it hurts performance as
more cpus are added. The kernel developers have been warning for some time that
the BKL was going to be eliminated, but it appears that nVidia failed to heed
that warning. With 2.6.39, the header file that implements that form of locking,
which is named smp_lock.h, has been eliminated. The nVidia build code is
chocking on an attempt to include that header file.
Some people on the Ubuntu forums
(http://ubuntuforums.org/showthread.php?p=10631714) reported that it was
sufficient to remove the offending include; however, that will work only if
nVidia fixed the locking but forgot to remove that include statement. Of course,
the worst case will be random crashes. 
It might help if you post a bug on nVidia’s bugzilla, or add your voice to the
bug that is likely already posted.
So this is a really big deal if you want to load the nVIDIA proprietary video driver if indeed it will no longer work with kernel 2.6.39 due to the removal of the BKL from the kernel. I would guess we need some sort of outrage from the Linux community on this problem. Do we know if the same issue will exist with AMD video drivers as well? You can make your bug report to nVIDIA here:
Thank You,
On 04/10/2011 09:36 AM, jdmcdaniel3 wrote:
>
> So this is a really big deal if you want to load the nVIDIA proprietary
> video driver if indeed it will no longer work with kernel 2.6.39 due to
> the removal of the BKL from the kernel. I would guess we need some sort
> of outrage from the Linux community on this problem. Do we know if the
> same issue will exist with AMD video drivers as well?
I certainly do not know. By preference I try not to use any proprietary,
closed-source drivers for anything. The only violation of that principle is on
one Mythtv system that needs the nVidia driver to be able to handle TV. That one
runs a 2.6.29 kernel, thus it has no problem.
Most vendors keep up with kernel developments and are likely to have eliminated
the BKL already. Given AMD’s close ties with Linux, their driver is likely to be OK.
I certainly do not know. By preference I try not to use any proprietary,
closed-source drivers for anything. The only violation of that principle is on
one Mythtv system that needs the nVidia driver to be able to handle TV. That one
runs a 2.6.29 kernel, thus it has no problem.
Most vendors keep up with kernel developments and are likely to have eliminated
the BKL already. Given AMD’s close ties with Linux, their driver is likely to be OK.
Well the issues of closed verse open source drivers is beyond the scope of this thread though I understand why it is done. If you sell hardware, then it needs to run on the current software. Anytime there is a big change, as I believe the BKL is, you will have companies that pull up the rear on support and it is not just the small ones either. If nVIDIA were to give up the fight and stop supporting Linux, then their product will be going over board in this house as well. Until then, I will hold tight and see what develops.
Thank You,
On Sun, 2011-04-10 at 16:36 +0000, jdmcdaniel3 wrote:
> > I certainly do not know. By preference I try not to use any proprietary,
> > closed-source drivers for anything. The only violation of that
> > principle is on
> > one Mythtv system that needs the nVidia driver to be able to handle TV.
> > That one
> > runs a 2.6.29 kernel, thus it has no problem.
> >
> > Most vendors keep up with kernel developments and are likely to have
> > eliminated
> > the BKL already. Given AMD’s close ties with Linux, their driver is
> > likely to be OK.Well the issues of closed verse open source drivers is beyond the scope
> of this thread though I understand why it is done. If you sell
> hardware, then it needs to run on the current software. Anytime there
> is a big change, as I believe the BKL is, you will have companies that
> pull up the rear on support and it is not just the small ones either.
> If nVIDIA were to give up the fight and stop supporting Linux, then
> their product will be going over board in this house as well. Until
> then, I will hold tight and see what develops.
>
> Thank You,
>
>
Hi
I think you are missing the point of what the rc in the kernel is…
for testing, so that companies like Nvidia can test and fix any bugs to
ensure when the ‘official’ release is available that things work and a
relatively bug free.
For example my expectation if I was using my eGalax touch screen
(semi-closed driver) with the kernel and it wasn’t working properly. I
would contact eGalax with a bug report, likewise maybe a browse of the
Nvidia forums and or bug reports may be in order before jumping the gun?
Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.32.29-0.3-default
up 4 days 8:53, 2 users, load average: 0.27, 0.15, 0.04
GPU GeForce 8600 GTS Silent - Driver Version: 260.19.26
Hi
I think you are missing the point of what the rc in the kernel is…
for testing, so that companies like Nvidia can test and fix any bugs to
ensure when the ‘official’ release is available that things work and a
relatively bug free.
For example my expectation if I was using my eGalax touch screen
(semi-closed driver) with the kernel and it wasn’t working properly. I
would contact eGalax with a bug report, likewise maybe a browse of the
Nvidia forums and or bug reports may be in order before jumping the gun?
I did use this opportunity to post a bug report with nVIDIA about kernel 2.6.39-rc2 with their nVIDIA driver 260.19.44 & 270.30 when used on my nVIDIA 450 GPU. I think I understand rc kernel testing and I expect that issues can arise with any software. And I personally do not know why the nVIDIA driver is failing with kernel 2.6.39-rc2 other than what I just read here in the forum.
Thank You,
here is a fix i came up with.
ftp://download.nvidia.com/XFree86/Linux-x86_64/270.30/NVIDIA-Linux-x86_64-270.3$sh
NVIDIA-Linux-x86_64-270.30.run --extract-only
cd NVIDIA-Linux-x86_64-270.30/kernel
perl -pi -e ‘s/.smp_lock.h.
//’ nv-linux.h
cd …
./nvidia-installer
here is a fix i came up with.
ftp://download.nvidia.com/XFree86/Linux-x86_64/270.30/NVIDIA-Linux-x86_64-270.3$sh
NVIDIA-Linux-x86_64-270.30.run --extract-only
cd NVIDIA-Linux-x86_64-270.30/kernel
perl -pi -e ‘s/.smp_lock.h.
//’ nv-linux.h
cd …
./nvidia-installer
Well, not wishing to look stupid, but what is this fix doing exactly? And thanks for your help and efforts.
Thank You,
On 04/12/2011 10:06 PM, jdmcdaniel3 wrote:
>
>> here is a fix i came up with.
>> ftp://download.nvidia.com/XFree86/Linux-x86_64/270.30/NVIDIA-Linux-x86_64-270.3$sh
>>
>> NVIDIA-Linux-x86_64-270.30.run --extract-only
>> cd NVIDIA-Linux-x86_64-270.30/kernel
>> perl -pi -e ‘s/.smp_lock.h.
//’ nv-linux.h
>> cd …
>> ./nvidia-installer Well, not wishing to look stupid, but what is this fix doing exactly?
> And thanks for your help and efforts.
The perl statement is finding the line in
NVIDIA-Linux-x86_64-270.30/kernel/nv-linux.h that has the “include
<linux/smp_lock.h>” line and deletes it. If nVidia did remove the BKL and only
forgot to remove the header call, this will work.
2.6.39-rc3-1 appeared in the Kernel/HEAD repositories for both 11.3 and 11.4. Each installed and booted, with some less than encouraging results. The most discouraging finding was the absence of the long-awaited corrections for the Intel Arrandale/Ironlake problem(s). The corrections (I deliberately refrain from using “fixes”), first apparent in 2.6.38-rc1 and -rc2 were regressed (or otherwise met their demise) with 2-6-38-rc3, and have been conspicuous by their absence since that release. <sigh>
As for remaining experiences:
11.3: Smooth boot, login and operation (posting from the updated kernel here).
11.4: “preload-kmp-desktop” fails to install, citing a requirement of 2-6.32-32. Boot is very sluggish, and a long delay following entry of user & password. After login, behavior similar to 11.3.