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

So, kernel 3.3-rc1 has been released. And so we start another beta thread for your testing results. I tried to find something on the latest kernel, but I seem to be coming up short today with only this find, but you can post more if you see it.

http://www.h-online.com/open/imgs/45/7/5/5/5/3/7/kl_15millionloc-ff493333a135672e.png

Kernel Log: 15,000,000 lines of code, 3.0 promoted to long-term kernel - The H Open Source: News and Features

Well I did compile the latest kernel without error but alas, the nVIDIA proprietary video driver would not install. I tried the 64 bit versions for 290.10 and the beta 295.09 and neither one would install into kernel-3.3-rc1. So, if you did get it to work or found a different version that did install, you must let me know here.

And so, we also want to know if you have installed and tried out the new kernel for testing: Kernel 3.3

I am using sakc to compile and install the kernel:S.A.K.C. - SUSE Automated Kernel Compiler - Version 2.50 - Blogs - openSUSE Forums

You can use sgtb, to fetch and stay up with the latest kernel releases if you with:S.G.T.B. - SuSE Git Kernel Tarball Creator - Version 1.78 - Blogs - openSUSE Forums

Thank You,

I have not yet tested v3.3-rc1, but I tested v3.2-gitX pulled on Jan 18, which
is essentially the same thing. I found no problems.

My issue is the same old thing that comes up when you insist on installing the nVIDIA driver. Mostly they work, but ever so often they do not. Since there is a newer driver version, it most likely will be updated to work in the future. But in the end, the loss is mine wanting to use their driver with every released kernel version.

While I have got your attention, I have a question. Have you ever used any of these in creating your kernel configuration?

make localmodconfig

OR

make localyesconfig

OR

chmod +x ./scripts/kconfig/streamline_config.pl ; ./scripts/kconfig/streamline_config.pl > ./config_strip ; mv ./config_strip ./.config

Anyone of the above configs can cause the kernel compiles to drop to a 1/4 of normal, but any module not presently loaded, is excluded and not useable later it would seem. Don’t have that thumb drive plugged in? Can’t use it later then perhaps. So any comment you might have on this subject is very important to me.

Thank You,

On 01/19/2012 08:36 PM, jdmcdaniel3 wrote:

> My issue is the same old thing that comes up when you insist on
> installing the nVIDIA driver. Mostly they work, but ever so often they
> do not. Since there is a newer driver version, it most likely will be
> updated to work in the future. But in the end, the loss is mine wanting
> to use their driver with every released kernel version.

Since kernel 3.1, nouveau works with my nVidia adapter, and I do not need any
further acceleration. Besides, a tainted kernel would not work for me at all in
my kernel testing.

> While I have got your attention, I have a question. Have you ever used
> any of these in creating your kernel configuration?
>
>
> Code:
> --------------------
> make localmodconfig
> --------------------
> Code:
> --------------------
> make localyesconfig
> --------------------
> Code:
> --------------------
> chmod +x ./scripts/kconfig/streamline_config.pl ; ./scripts/kconfig/streamline_config.pl> ./config_strip ; mv ./config_strip ./.config
> --------------------
>
>
> Anyone of the above configs can cause the kernel compiles to drop to a
> 1/4 of normal, but any module not presently loaded, is excluded and not
> useable later it would seem. Don’t have that thumb drive plugged in?
> Can’t use it later then perhaps. So any comment you might have on this
> subject is very important to me.

As far as I can tell, options 1 & 3 are the same thing. Why there is a Perl
script to do that I don’t know. Option 2 does the same thing, but compiles
everything into the kernel, rather than a module.

Incidentally,
perl scripts/kconfig/streamline_config.pl > ./config_str
would avoid the need to do the chmod step.

The intent of those commands is to eliminate any modules not currently in use by
the kernel, and they do eliminate anything not loaded when they are run. I never
build the full 2000+ modules of a distribution kernel. My current .config has
been tailored to generate 519 modules. There are probably a few that are not
needed, but getting rid of them is more trouble that it is worth. A full kernel
build on a 2.0 GHz, dual-core AMD laptop that has a 7200 rpm hard drive and 3 GB
RAM takes a little over 20 minutes using the -j4 switch on the make.

If there is a module that you know you will need later, you can always modprobe
it before you generate the .config. In the case of the thumb drive, plug it in
once. Any needed modules will be loaded, and they will stay loaded. “modprobe
-r” or rmmod are the only ways to unload any module.

For several slow machines on which I do testing, including a 1.6 GHz netbook,
and an ancient laptop with a 450 MHz AMD K6 cpu, I use my desktop with a 3.5 GHz
dual core CPU, 4 GB of RAM, and 10,000 rpm disks to cross-compile the 32-bit
kernels on a 64-bit system. The source tree is exported via NFS, and the only
thing the target host does is the ‘make modules_install install’ step. On that
K6, that takes about as long as the compile. If I get full access, I use -j6 there.

I hope this answers your questions.

Yes, Yes, that is great information. First, I did not understand what option two was doing different, so now I know. As for option 3, one difference, and I do not know why, is I can get the nVIDIA driver to compile if I use option 3 against the new kernel, but I can not do so with option 1, so for some reason, they are not exactly the same. Another question for you. So, to get the config for the running kernel we can use: zcat /proc/config.gz >.config, but, once you use options, 1, 2 or 3 above, doing this to get your config will be forever at the reduced point it would seem. I can go and get a config from the boot folder, put there by default, but what would be the recommended way to restore your self back to point before you ever ran options 1, 2 or 3? And finally, would you recommend options 1, 2 or 3 to anyone that understand just what they do? I have integrated this into a version of sakc not yet released. I can restore the config from the default folder, but not sure if that is what you originally start with or just what it is for sure. In openSUSE 11.4, the file is called config-2.6.37.6-0.9-desktop. Again, any comments you would have would be great and thank you.

Thank You,

On 01/20/2012 06:06 AM, jdmcdaniel3 wrote:

> Yes, Yes, that is great information. First, I did not understand what
> option two was doing different, so now I know. As for option 3, one
> difference, and I do not know why, is I can get the nVIDIA driver to
> compile if I use option 3 against the new kernel, but I can not do so
> with option 1, so for some reason, they are not exactly the same.
> Another question for you. So, to get the config for the running kernel
> we can use: zcat /proc/config.gz>.config, but, once you use options,
> 1, 2 or 3 above, doing this to get your config will be forever at the
> reduced point it would seem. I can go and get a config from the boot
> folder, put there by default, but what would be the recommended way to
> restore your self back to point before you ever ran options 1, 2 or 3?
> And finally, would you recommend options 1, 2 or 3 to anyone that
> understand just what they do? I have integrated this into a version of
> sakc not yet released. I can restore the config from the default
> folder, but not sure if that is what you originally start with or just
> what it is for sure. In openSUSE 11.4, the file is called
> config-2.6.37.6-0.9-desktop. Again, any comments you would have would
> be great and thank you.

One of the configuration options determines if the kernel build process stores a
copy of the configuration so that it is available /proc/config.gz. The openSUSE
kernels all have this option selected (CONFIG_IKCONFIG=y). This information is
always the configuration of the running kernel. Any options not selected will
never appear in that spot again unless you run ‘make xconfig’ or ‘make
menuconfig’ to restore them. You could also edit .config, but I don’t recommend
that for most people. The only safe way to do that is to delete the line that
says “# CONFIG_BLA_BLA is not set”. Then when you run ‘make oldconfig’ or
‘make’, you will be asked the questions pertaining to that option.

The file /boot/config-<kernel_version> contains a copy of the configuration used
to generate that particular kernel. It is identical to what would be in
/proc/config.gz if you had booted that standard kernel, and it is what you
would have had when you started.

So, using the commands like ‘make xconfig’ or ‘make menuconfig’ to restore the kernel .config are both menu driven kernel configuration programs. Must you add back in each kernel module that was removed by using the previous options 1,2 or 3 manually in these menus? Or, does running these menus and saving the kernel restore all of the removed modules? I hope you understand my question. If you must manually add back each kernel module, then saving and restoring the configuration you used before my options 1, 2 or 3 were run would be a better option or using the original kernel config as saved in the /boot folder. Its one thing to understand how these work and another to automate such a proces for many to use and so an alleged safe method must be determined to restore a good kernel configuration, which is my task to complete.

Thank You,

On 01/20/2012 06:06 PM, jdmcdaniel3 wrote:
> So, using the commands like ‘make xconfig’ or ‘make menuconfig’ to
> restore the kernel .config are both menu driven kernel configuration
> programs. Must you add back in each kernel module that was removed by
> using the previous options 1,2 or 3 manually in these menus? Or, does
> running these menus and saving the kernel restore all of the removed
> modules? I hope you understand my question. If you must manually add
> back each kernel module, then saving and restoring the configuration you
> used before my options 1, 2 or 3 were run would be a better option or
> using the original kernel config as saved in the /boot folder. Its one
> thing to understand how these work and another to automate such a proces
> for many to use and so an alleged safe method must be determined to
> restore a good kernel configuration, which is my task to complete.

You use ‘make xconfig’ or ‘make menuconfig’ to update .config. Both of them read
the current .config, allow the user to change parameters, and optionally rewrite
…config. The only difference is that menuconfig uses ncurses to implement the
menus (think YaST from an ‘init 3’ console), and xconfig gives you a qt4 GUI.
They are useful when you want to add or delete a few drivers and/or options.
They are not meant for automated operations. When you want to go all the way
back to the distribution configuration, the file in /boot/config… is the only
safe way. As I said, I would never do that as I generally compile 10-15 kernels
on an average day, and generating all those extraneous modules is something I
cannot afford.

And I absolutely understand and thank you so much for your help and great information!

Well, on another subject, anyone wanting to compile in the **nVIDIA **driver I have come up with a way that requires moving a few kernel source files to a different location, thus allowing the nVIDIA driver to install. You must first Compile and/or install the latest kernel 3.3-rc1, but before you reboot, open up a terminal session and run the following command:

cd /lib/modules/3.3.0-rc1-0.9-desktop/source/arch/x86/include ; sudo cp generated/asm/*.h ./asm

This command will then allow the nVIDIA proprietary video driver 290.10 to install when using then newest kernel 3.3-rc1 and assumes you are using kernel-desktop.

Thank You,

http://www.h-online.com/open/imgs/45/7/6/0/1/2/9/kl_33_testing-d2e411f45d5cb823.png

So, I finally found something new for kernel 3.3 here: Kernel Log: Linux 3.3 goes into testing - The H Open Source: News and Features

http://www.h-online.com/open/imgs/45/7/6/0/1/2/9/TuxEatingRam-cbe1b210334e2205.png

Just a funny picture in the same story.

Thank You,

http://www.h-online.com/open/imgs/45/7/6/2/0/8/1/cominginlinux33_1_kicker-fee60f9bf53d8118.png

Kernel Log: Coming in 3.3 (Part 1) - Networking - The H Open Source: News and Features

Finally, the first article of many at the H Open Source just for the new kernel 3.3, now with Networking first up for discussion.

Thank You,

Resuming Kernel 3.3 testing after a brief interruption, I have encountered a roadblock. While I have compiled kernels from the kernel.org source(s), I generally test from the Kernel/HEAD and Kernel/vanilla repositories. Apparently, Kernel/vanilla has gone missing from Index of /repositories/Kernel:. (Actually, the directory entry remains, but the repository is empty). Further, Kernel/linux-next is similarly absent.

A quick perusal of openSUSE Kernel Resources and into the “vanilla” and “linux-next” branches reveals no new information.

Last 3.3 kernel (3.3rc1-1) crashes and burns quite quickly on Intel graphics, and dies somewhat slower with Radeon. While I can easily compile a 3.3rc1 on the Intel platform, the much older and slower Radeon would take an unreasonable amount of time. However, it appears that kernel.org has nothing newer than the orphaned 3.3rc1-vanilla kernel available.

Have I missed the memo ?

They are in standard everything else has been empty for some time

Well tonight I have installed kernel 3.3-rc2 without error. Everything is working fine. I have not seen a new post at the H Online yet for rc2, but I will keep looking. http://www.kernel.org/pub/linux/kernel/v3.0/testing/linux-3.3-rc2.tar.bz2

I also have installed the latest nVIDIA beta driver 295.17 and I had to make the same fix required by all to get the driver to compile:

cd /lib/modules/3.3.0-rc2-0.9-desktop/source/arch/x86/include ; sudo cp generated/asm/*.h ./asm

or

cd /lib/modules/<kernel name>/source/arch/x86/include ; sudo cp generated/asm/*.h ./asm

So far, 295.17 is working better than 295.09 which had a problem with KDE for some reason. You can get the latest 64 bit nVIDIA driver this way using terminal:

cd ~/Downloads ; wget ftp://download.nvidia.com/XFree86/Linux-x86_64/295.17/NVIDIA-Linux-x86_64-295.17.run

Thank You,

I last pulled 3.3rc1 -vanilla from the now-empty Index of /repositories/Kernel:/vanilla repositories on 2012.01.20, so this brief interval may qualify as “some time”.

As for “in standard”,

Index of /repositories/Kernel:/HEAD/standard has kernel 3.2.0-7.3 (all flavors)

Index of /repositories/Kernel:/openSUSE-12.1/standard contains kernel 3.1.9-6.1 (all flavors)

Index of /repositories/Kernel:/stable/standard contains kernel 3.2.2-2.1 (all flavors)

All above references current as of this writing. Is there a fourth (or further) “standard” repository that I should look for kernel 3.3 ?

Was there any announcement, correspondence or other communications indicating such changes ? Apparently, openSUSE Kernel Resources, Branch info and Packages are no longer current.

Well I sure do not know the answer to your question except that the start of the new year saw a couple of things dropped like our weekly news release, so not keeping up with kernels may be another dropped ball perhaps. Since you can do the same on your own, I am not sure what to say here that really matters.

Thank You,

Kernel 3.3 rc3 is out and is in the head repository Index of /repositories/Kernel:/HEAD/standard/x86_64

Does anyone know if the …/stable/standard/ repo has updated to gcc46? Last time I tried it nvidia had to be compiled with gcc45.

I have not recently had an issue compiling in the nVIDIA driver due to a gcc version problem, neither in openSUSE 11.4 or in 12.1. Perhaps more information might be helpful to understand what is wrong.

Thank You,

So I have installed kernel-3.3-rc3 tonight and it is working just fine. I have also installed the nVIDIA driver 295.17 which still requires the fix mentioned before for it to compile. I am now playing around with DKMS and using it to load the nVIDIA driver and I have that working under openSUSE 11.4 just fine using my new bash utility I call “S.A.N.D.I. - SuSE Automated NVIDIA Driver Installer” using “DKMS - Dynamic Kernel Module Support for the nVIDIA Video Driver”. I will be releasing it shortly but I am having issues with DKMS and openSUSE 12.1 for now, but I am working to solve that problem.

Thank You,