Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39

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

  1. #1
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Smile 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.



    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,
    Last edited by jdmcdaniel3; 20-Jan-2012 at 20:33.
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  2. #2
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,267

    Default Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    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.


  3. #3
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Question Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    Quote Originally Posted by lwfinger View Post
    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?

    Code:
    make localmodconfig
    OR

    Code:
    make localyesconfig
    OR

    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.

    Thank You,
    Last edited by jdmcdaniel3; 19-Jan-2012 at 19:30.
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  4. #4
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,267

    Default Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    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.

  5. #5
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Question Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    Quote Originally Posted by lwfinger View Post
    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,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  6. #6
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,267

    Default Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    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.

  7. #7
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Question Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    Quote Originally Posted by lwfinger View Post
    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,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  8. #8
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,267

    Default Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    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.


  9. #9
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Smile Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!

    Quote Originally Posted by lwfinger View Post
    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:

    Code:
    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,
    Last edited by jdmcdaniel3; 20-Jan-2012 at 20:44.
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

  10. #10
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,500
    Blog Entries
    48

    Smile Re: Linux Kernel 3.3 RCX has Been Released To Test - Post YourCommentsHere!



    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



    Just a funny picture in the same story.

    Thank You,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

Page 1 of 4 123 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •