Linux Kernel 3.4 RCX has Been Released To Test - Post Your Comments Here!

English Install/Boot/Login
1

Well tonight 3-31-12, the last day of March 2012, kernel 3.4-rc1 has been released for testing which you can find here: http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.4-rc1.tar.bz2

I have not found any posts yet on the new kernel, but will place them here when I find them. I can say that I was able to compile kerne-3.4-rc1 without a problem using SAKC. However, the nVIDIA proprietary video driver does not install. It does not install with any fix I have used for kernel 3.3 so I guess there are more changes with kernel 3.4 over what was changed with kernel 3.4. I hope its temporary, but it is not looking good for nVIDIA at all. They fell behind using in getting their driver to work with kernel 3.3 and none of those fixes work with kernel 3.4. So, we will see what this means for anyone using nVIDIA who would like to stay up with the latest kernel releases.

We want anyone to post comments here about the new kernel, if you are using it or if you have questions about it. Let the kernel testing begin …

Thank You,

2

The following patch file can be applied to the NVIDIA-Linux-x86_64-295.33.run or NVIDIA-Linux-x64-295.33.run driver to allow it to install into the latest kernel-3.4-rcx. Copy the text from the code block below and pasted into your favorite text editor and then save it as the text file called NVIDIA-295.33.patch:

Index: NVIDIA-Linux-x86-295.33/kernel/conftest.sh
===================================================================
--- kernel.orig/conftest.sh
+++ kernel/conftest.sh
@@ -95,7 +95,7 @@ build_cflags() {
         fi
     fi
 
-    CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS $AUTOCONF_CFLAGS"
+    CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS -I$OUTPUT/arch/x86/include/generated $AUTOCONF_CFLAGS"
 
     test_xen
 
@@ -126,7 +126,7 @@ build_cflags() {
     CFLAGS="$BASE_CFLAGS $MACH_CFLAGS $OUTPUT_CFLAGS -I$HEADERS $AUTOCONF_CFLAGS"
 
     if  "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then
-        CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$SOURCES/arch/x86/include/generated"
+        CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include -I$OUTPUT/arch/x86/include/generated"
     elif  "$ARCH" = "ARMv7" ]; then
         CFLAGS="$CFLAGS -I$SOURCES/arch/arm/include -I$SOURCES/arch/arm/include/generated"
     fi
@@ -512,7 +512,7 @@
             # and if it as an 'event' member.
             #
             echo "$CONFTEST_PREAMBLE
-            #include <asm/system.h>
+            #include <asm/switch_to.h>
             #include <linux/pm.h>
             void conftest_pm_message_t(pm_message_t state) {
                 pm_message_t *p = &state;
@@ -965,11 +965,12 @@ compile_test() {
             #
             echo "$CONFTEST_PREAMBLE
             #include <linux/acpi.h>
+            #include <acpi/acpixf.h>
             void conftest_acpi_walk_namespace(void) {
                 acpi_walk_namespace();
             }" > conftest$$.c
 
-            $CC $CFLAGS -c conftest$$.c > /dev/null 2>&1
+            #CC $CFLAGS -c conftest$$.c > /dev/null 2>&1
             rm -f conftest$$.c
 
             if  -f conftest$$.o ]; then
@@ -980,6 +981,7 @@ compile_test() {
 
             echo "$CONFTEST_PREAMBLE
             #include <linux/acpi.h>
+        #include <acpi/acpixf.h>
             void conftest_acpi_walk_namespace(void) {
                 acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL, NULL);
             }" > conftest$$.c
@@ -996,6 +998,7 @@ compile_test() {
 
             echo "$CONFTEST_PREAMBLE
             #include <linux/acpi.h>
+            #include <acpi/acpixf.h>
             void conftest_acpi_walk_namespace(void) {
                 acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL);
             }" > conftest$$.c
@@ -1604,6 +1607,9 @@ case "$6" in
             fi
         fi
 
+    RET=0
+    SELECTED_MAKEFILE=Makefile.kbuild
+
         if  "$RET" = "0" ]; then
             ln -s $SELECTED_MAKEFILE Makefile
             exit 0
Index: NVIDIA-Linux-x86-295.33/kernel/nv-linux.h
===================================================================
--- kernel.orig/nv-linux.h
+++ kernel/nv-linux.h
@@ -111,7 +111,7 @@
 #include <linux/timer.h>
 
 #include <asm/div64.h>              /* do_div()                         */
-#include <asm/system.h>             /* cli, sli, save_flags             */
+#include <asm/switch_to.h>          /* cli, sli, save_flags             */
 #include <asm/io.h>                 /* ioremap, virt_to_phys            */
 #include <asm/uaccess.h>            /* access_ok                        */
 #include <asm/page.h>               /* PAGE_OFFSET                      */

To then apply the patch you can use S.A.N.D.I. - SuSE Automated NVIDIA Driver Installer - Version 1.45 or manuallly with the following command:

sh ./NVIDIA-Linux-x86_64-295.33.run --apply-patch NVIDIA-295.33.patch

which creates the file NVIDIA-Linux-x86_64-295.33-custom.run

OR

sh ./NVIDIA-Linux-x64-295.33.run --apply-patch NVIDIA-295.33.patch

which creates the file NVIDIA-Linux-x64-295.33-custom.run

Thank You,

3

http://www.h-online.com/open/imgs/45/7/9/0/1/5/3/kl_radeon_gpus-5d711f1150ff22a9.png

by Thorsten Leemhuis

Soon, the kernel will support several AMD graphics cores that are used in recent Radeon graphics cards and in various upcoming processors. In systems with Intel graphics, using hibernation can cause memory corruption. The development of Linux 3.4 has started.

Read More …

Thank You,

4

So after over coming the ability to install the nVIDIA driver into kernel 3.4-rc1, I ran into another problem tonight. Not sure what was wrong, but Samba was cut off from the outside world. Might have been something to do with the Firewall or an incompatibility with Samba, but when I switched back to kernel 3.3, all was well again with Samba. Not sure what that means is wrong when I have kernel 3.4-rc1 running. If anyone else has heard of the issue, please let me know.

Thank You,

5

jdmcdaniel3 wrote:

>
> The following patch file can be applied to the
> NVIDIA-Linux-x86_64-295.33.run or NVIDIA-Linux-x64-295.33.run driver
> to
> allow it to install into the latest kernel-3.4-rcx. Copy the text
> from
> the code block below and pasted into your favorite text editor and
> then
> save it as the text file called NVIDIA-295.33.patch:
>
>
> Code:
> --------------------
> Index: NVIDIA-Linux-x86-295.33/kernel/conftest.sh
> ===================================================================
> — kernel.orig/conftest.sh
> +++ kernel/conftest.sh
> @@ -95,7 +95,7 @@ build_cflags() {
> fi
> fi
>
> - CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS $AUTOCONF_CFLAGS"
> + CFLAGS="$CFLAGS $OUTPUT_CFLAGS -I$HEADERS
> -I$OUTPUT/arch/x86/include/generated $AUTOCONF_CFLAGS"
>
> test_xen
>
> @@ -126,7 +126,7 @@ build_cflags() {
> CFLAGS="$BASE_CFLAGS $MACH_CFLAGS $OUTPUT_CFLAGS -I$HEADERS
> $AUTOCONF_CFLAGS"
>
> if “$ARCH” = “i386” -o “$ARCH” = “x86_64” ]; then
> - CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include
> -I$SOURCES/arch/x86/include/generated"
> + CFLAGS="$CFLAGS -I$SOURCES/arch/x86/include
> -I$OUTPUT/arch/x86/include/generated" elif “$ARCH” = “ARMv7” ];
> then CFLAGS="$CFLAGS -I$SOURCES/arch/arm/include
> -I$SOURCES/arch/arm/include/generated" fi
> @@ -512,7 +512,7 @@
> # and if it as an ‘event’ member.
> #
> echo "$CONFTEST_PREAMBLE
> - #include <asm/system.h>
> + #include <asm/switch_to.h>
> #include <linux/pm.h>
> void conftest_pm_message_t(pm_message_t state) {
> pm_message_t p = &state;
> @@ -965,11 +965,12 @@ compile_test() {
> #
> echo “$CONFTEST_PREAMBLE
> #include <linux/acpi.h>
> + #include <acpi/acpixf.h>
> void conftest_acpi_walk_namespace(void) {
> acpi_walk_namespace();
> }” > conftest$$.c
>
> - $CC $CFLAGS -c conftest$$.c > /dev/null 2>&1
> + #CC $CFLAGS -c conftest$$.c > /dev/null 2>&1
> rm -f conftest$$.c
>
> if -f conftest$$.o ]; then
> @@ -980,6 +981,7 @@ compile_test() {
>
> echo “$CONFTEST_PREAMBLE
> #include <linux/acpi.h>
> + #include <acpi/acpixf.h>
> void conftest_acpi_walk_namespace(void) {
> acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL, NULL);
> }” > conftest$$.c
> @@ -996,6 +998,7 @@ compile_test() {
>
> echo “$CONFTEST_PREAMBLE
> #include <linux/acpi.h>
> + #include <acpi/acpixf.h>
> void conftest_acpi_walk_namespace(void) {
> acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL);
> }” > conftest$$.c
> @@ -1604,6 +1607,9 @@ case “$6” in
> fi
> fi
>
> + RET=0
> + SELECTED_MAKEFILE=Makefile.kbuild
> +
> if “$RET” = “0” ]; then
> ln -s $SELECTED_MAKEFILE Makefile
> exit 0
> Index: NVIDIA-Linux-x86-295.33/kernel/nv-linux.h
> ===================================================================
> — kernel.orig/nv-linux.h
> +++ kernel/nv-linux.h
> @@ -111,7 +111,7 @@
> #include <linux/timer.h>
>
> #include <asm/div64.h> / do_div()
> # /
> -#include <asm/system.h> / cli, sli, save_flags
> /
> +#include <asm/switch_to.h> / cli, sli, save_flags
> /
> #include <asm/io.h> / ioremap, virt_to_phys
> # /
> #include <asm/uaccess.h> / access_ok
> # /
> #include <asm/page.h> / PAGE_OFFSET
> # */
>
> --------------------
>
>
> To then apply the patch you can use SANDI version 1.45 or manuallly
> with the following command:
>
>
> Code:
> --------------------
> sh ./NVIDIA-Linux-x86_64-295.33.run --apply-patch
> NVIDIA-295.33.patch
>
> which creates the file NVIDIA-Linux-x86_64-295.33-custom.run
> --------------------
>
>
> OR
>
>
> Code:
> --------------------
> sh ./NVIDIA-Linux-x64-295.33.run --apply-patch NVIDIA-295.33.patch
>
> which creates the file NVIDIA-Linux-x64-295.33-custom.run
> --------------------
>
>
> Thank You,
>
Just quick question to clarify my brain. Do I run the script as route,
or if I use Sandi does it need to run as root? I also assume I run the
final patched script at run level 3 as root like normal.

I will be on 12.2 MS2 (rc6 is kernel version) cannot look at it right
now,) Thanks for all your work on the time saving scripts you have
produced.

Sending this from my 12.1 system.

Russ
openSUSE 12.1(3.1.9-1.4-desktop x86_64)|KDE Platform Version
4.8.1 (4.8.1 “release 483”|Intel core2duo 2.5 MHZ,|8GB DDR3|GeForce
8400GS(NVIDIA-Linux-x86_64-295.20)

6

Just quick question to clarify my brain. Do I run the script as route, or if I use Sandi does it need to run as root? I also assume I run the final patched script at run level 3 as root like normal. I will be on 12.2 MS2 (rc6 is kernel version) cannot look at it right now,) Thanks for all your work on the time saving scripts you have produced. Sending this from my 12.1 system. – Russ openSUSE 12.1(3.1.9-1.4-desktop x86_64)|KDE Platform Version 4.8.1 (4.8.1 “release 483”|Intel core2duo 2.5 MHZ,|8GB DDR3|GeForce 8400GS(NVIDIA-Linux-x86_64-295.20)

  1. If you run SANDI or my LNVHW script, it will ask for the root user password when required as you normally do not start the application as root. However, if you run them from runlevel 3, with no desktop loaded, its OK to be root when they are started.
  2. The instructions I gave in the message thread is how to patch the nVIDIA driver to work with openSUSE 12.2 and the patching would/could be done from terminal from your desktop as a standard user.
  3. Once the nVIDIA driver is patched and has the -custom name in its whole name, it can then be installed manually from runlevel 3, with or without SANDI or LNVHW.

If you don’t mind reloading the driver on each kernel update, then use LNVHW. If you want the nVIDIA driver to be loaded automatically, then use SANDI. There is a BIG issue with the nVIDIA driver in that it needs one fix to work with Kernel 3.3 and yet a different fix for kernel 3.4 and you don’t need either fix with kernel 3.2 or lower. It is kind of a mess, but trying to use SANDI might be a problem until there is a single nVIDIA driver you can load that works with all present kernels and that is not the case right now. I cam up with a method to allow SANDI to work with kernel’s 3.2 and below with a fix for kernel 3.3, but no automated way to mix in kernel 3.4 as well just yet. Stay tuned as nVIDIA might do the right thing and start supporting the latest kernel’s without all of this rig-a-ma-row, but I am not holding my breath for it right now.

Thank You,

7

From ** Linus Torvalds **
Date **Sat, 31 Mar 2012 16:58:35 -0700 **
Subject ** Linux 3.4-rc1 **

Ok, it’s been two weeks, and the merge window is over. Linux 3.4-rc1 has been pushed out to the git servers, and the tar-ball and patches are going out as I type this (probably done by the time I’m done). Read More …

Thank You,

8

http://www.h-online.com/imgs/43/8/0/8/7/5/7/Kernel_Log_Penguin.jpg-2772ff8328727478.jpeg

Two weeks after Linux 3.3 was released, Linus Torvalds has announced the availability of the first release candidate for Linux 3.4. As usual, this step signals the end of the merge window at the beginning of the development cycle; during the merge window, Torvalds integrates the major changes for a new Linux version and about seven-eighths of all changes. Apart from a few stragglers, mainly minor and low-risk changes will be made in the stabilising phase that has now begun.

Read More …

Thank You,

9

http://www.h-online.com/open/imgs/45/8/1/0/4/2/1/kl_120404-b5cd042f7eb8db44.png

by Thorsten Leemhuis

New versions of the Linux kernel fix a bug in Intel graphics drivers which could cause memory corruption. AMD has released X.Org drivers for its new Trinity processors. In September there will be a conference for X developers in Nuremberg. Progress has been made on GPGPU support in Mesa 3D.

Read More …

Thank You,

10

http://www.h-online.com/imgs/43/8/1/0/4/5/0/KLgraphics_logo80-c49a6ad8c77572fc.png

Linus Torvalds has applied a patch for inclusion in Linux 3.4 which will mean this kernel version will, by default, use the RC6 power-saving technology of Sandy Bridge processors and their GPUs. Since RC6 typically reduces the idle power consumption by around 3 to 5 watts, the change will extend the battery life of notebook PCs significantly and reduce noise levels as the fans will have to remove less heat.

Read More …

Thank You,

11

http://www.h-online.com/imgs/43/8/1/0/1/1/9/Linux_Foundation200-0be425e395710e46.png

Approximately 7,800 different developers at around 800 companies have contributed changes to the Linux kernel since Linux 2.6.11 was released in March 2005. Almost 18% of modifications were developed by volunteers who are known to contribute to Linux in their spare time; however, at least 75% were contributed by developers who make their living by working on Linux. These figures are based on the number of changes – this results in a one-line change counting the same as a large patch.

Read More …

Thank You,

12

If you go the http://www.lwfinger.com/nvidia_patches, you will find a patch file
to build Nvidia driver 295.33 using kernels 3.3 or 3.4-rc1. There is also a
README.txt that tells you what steps to take.

13

Thanks Larry for your help. I got the patch, but I am not seeing a README.txt file there. Am I missing something? Also, I wonder how I might look up reported issues with kernel 3.4-rc1? My Samba setup stopped working while using it and I wonder if it has been noticed by anyone else. As always, your help is very much appreciated.

Thank You,

14

On 04/06/2012 08:46 PM, jdmcdaniel3 wrote:
>
> lwfinger;2454268 Wrote:
>> If you go the ‘Index of /nvidia_patches’
>> (http://www.lwfinger.com/nvidia_patches), you will find a patch file
>> to build Nvidia driver 295.33 using kernels 3.3 or 3.4-rc1. There is
>> also a
>> README.txt that tells you what steps to take.
>
> Thanks Larry for your help. I got the patch, but I am not seeing a
> README.txt file there. Am I missing something? Also, I wonder how I
> might look up reported issues with kernel 3.4-rc1? My Samba setup
> stopped working while using it and I wonder if it has been noticed by
> anyone else. As always, your help is very much appreciated.

It seems that my server does not like file names that are all caps. I renamed it
to readme.txt, and now it is seen. Thanks for reporting this.

I have run 3.4-rc1 without any problems, but my laptop is not a Samba client or
server.

15

Thanks a bunch Larry for your help.

Thank You,

16

http://www.h-online.com/open/imgs/45/8/1/9/8/0/7/KLcomment_pv_220-517c02ca5ddae385.png

by Thorsten Leemhuis

**In the latest study by the Linux Foundation, Microsoft only just misses out on a spot among the top 20 groups and companies contributing to the Linux kernel. It has, however, achieved this only by dint of delivering bad code and then slowly improving it.
**
Read More …

Thank You,

17

On 04/07/2012 08:56 AM, jdmcdaniel3 wrote:
>
> [image:
> http://www.h-online.com/open/imgs/45/8/1/9/8/0/7/KLcomment_pv_220-517c02ca5ddae385.png]
>
> BY THORSTEN LEEMHUIS
> *In the latest study by the Linux Foundation, Microsoft only just
> misses out on a spot among the top 20 groups and companies contributing
> to the Linux kernel. It has, however, achieved this only by dint of
> delivering bad code and then slowly improving it.
> *
> ‘Read More …’ (http://tinyurl.com/7jnf64g)

Those statistics are always interesting to read, and one can certainly improve
their numbers by contributing the worst code that will be accepted, and then
improve it gradually.

To me, the most interesting statistic is in http://lwn.net/Articles/485058/
where there is a graph of the percentage of kernel changes submitted by
volunteers plotted against the kernel version. As the article states, the data
are noisy, but there appears to be a definite decrease with time. Perhaps that
trend is because much of the low-hanging fruit has been harvested, or it is
possible that many of the volunteers have been hired.

18

So, as a kernel developer, you have a lot more insight on this than I. Its OK to get a better job and I do wonder if they might still be able to contribute. But perhaps, a loss of talent is going on. I am not sure, but are you worried about such a trend as you are seeing?

Thank You,

19

On 04/07/2012 08:06 PM, jdmcdaniel3 wrote:

> So, as a kernel developer, you have a lot more insight on this than I.
> Its OK to get a better job and I do wonder if they might still be able
> to contribute. But perhaps, a loss of talent is going on. I am not
> sure, but are you worried about such a trend as you are seeing?

I think things are OK. For example, the guy that made mac80211 into something
really useful started as a volunteer when he was a graduate student. When he
graduated, he was quickly hired by Intel. He still works full time on mac80211,
but his contributions now count under their banner. There have been some major
contributors that have disappeared, but new ones come along. Someday, my hacking
will be over, but I’m certain that my load will be taken on by someone else.

20

So, if you have not heard it recently, we do appreciate your efforts with the kernel and here in the openSUSE forums. I do understand that lots of effort can go out for very little thanks in return and sometimes users can be as ungrateful as you could ever imagine. Even as others benefit from your work, you often hear very little at all like thanks or anything else for that matter. I think its mostly due to not understanding how all of this great stuff we call Linux is created with very bad comparisons to how Windows does it. As surely as the sun rises every day, we will be replaced someday when the time comes, but don’t give up the ghost just yet Larry, we have plenty more to do here before our day in the sun is done.

Thank You,