LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 03-31-2008, 09:43 AM   #1
stu_mueller
Member
 
Registered: Aug 2006
Location: England
Distribution: Slackware, Zenwalk
Posts: 114

Rep: Reputation: 15
hugesmp or not


OK folks,

I have installed slackware12 this week and have been busy configuring it and installing packages. The only thing I don't have working is my touchpad, but I'm working on it.

I installed the hugesmp kernel, and it all seems to work fine, the only issue I have is that it is slow to boot, but I guess thats to be expected from using one of the huge kernels...

I have read a few posts that say you should only use the huge kernels for install and use the generic kernels once installed. What is the reason for this? Is there a major problem with using a huge kernel now I have slack installed or can I keep on using this kernel?

If I do recompile my kernel, can I copy over the .config file from the huge kernel and then just remove features, rather than starting from the ground up?

I presume I could compile a kernel and keep it along side my existing huge kernel, untill I can make sure it boots OK, I would just need to make sure there is a modules directory and that rc.modules points to that directory?

I have recompiled a kernel before and ended up with no sound, this is what is making me nervous about recompiling my kernel. I don't want to lose support for anything that I currently have working

Stuart
 
Old 03-31-2008, 10:05 AM   #2
adriv
Member
 
Registered: Nov 2005
Location: Diessen, The Netherlands
Distribution: Slackware 14.1
Posts: 661

Rep: Reputation: 38
More info about hugesmp can be found here.
It's always good to compile your own kernel. A very good guide is Alien Bob's and yes, you can use the old config file (but you can read al about that on the link I posted to Alien's site).
 
Old 03-31-2008, 10:09 AM   #3
Calidore
LQ Newbie
 
Registered: Aug 2004
Posts: 10

Rep: Reputation: 1
As you said yourelf huge kernel is usualy only used for installs. After install you change it to generic one or recompile your own, well atleast that's what i do anyway.
There is no problem using the huge kernel if you want. but if you use the generic one or recompile your own the footprint of the kernel will be much smaller and you can free up some of the memory.
You can copy over your .config but dont forget to run "make oldconfig" (im not sure if this it the right command ).
I usualy delete the modules directory when recompiling my own kernel.
 
Old 03-31-2008, 09:16 PM   #4
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
The huge kernels have basically everything that can be compiled into the kernel, compiled into the kernel. It would I think waste memory (since more stuff is loaded), but would certainly increase bootup time if nothing else. It also becomes a problem when modules that shouldn't be loaded on your system are compiled into the kernel. Sometimes programs have difficulties with so many modules built into the kernel and you may have to blacklist modules. In general it's just better to switch to the generic kernel. Instructions for doing that are everywhere in these forums multiple times -- but I will say that you MUST create an initrd (initial ramdisk) in order to use the generic kernel (the filesystem modules are not compiled into the generic kernel and must be loaded in order to boot your system, hence the need for an initial ramdisk). If you have no idea what I'm talking about, search the forums for initrd and read /boot/README.initrd (which is a symlink to /usr/doc/mkinitrd-1.1.2/README.initrd).

If you don't believe me about using the generic kernel, here's a note from the man himself (Pat V):
Quote:
It is recommended that you use one of the generic kernels (either the plain
kernel-generic or kernel-generic-smp) for daily use. For most systems,
you should use the generic SMP kernel if it will run, even if your system
is not SMP-capable. Some newer hardware needs the local APIC enabled in
the SMP kernel, and theoretically there should not be a performance penalty
with using the SMP-capable kernel on a uniprocessor machine, as the SMP
kernel tests for this and makes necessary adjustments. Furthermore, the
kernel sources shipped with Slackware 12.0 are configured for SMP usage,
so you won't have to modify those to build external out-of-tree modules
(such as NVidia or ATI proprietary drivers) if you use the SMP kernel.
However, if you insist on using the huge kernel, read this (also from Pat):
Quote:
As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels; the huge kernel is primarily intended as
an "installer" and "emergency" kernel in case you forget to make an initrd.
However, if you do use one of the huge kernels, you will likely encounter
errors like this:
kobject_add failed for uhci_hcd with -EEXIST, don't try to register
These occur because the respective drivers are compiled statically into the
huge kernels but udev tries to load them anyway. These errors should be safe
to ignore, but if you really don't want them to appear, you can blacklist the
modules that try to load in /etc/modprobe.d/blacklist. However, make sure you
remove them from the blacklist if you ever decide to use the (recommended)
generic kernels.
Both quotes are from the "CHANGES_AND_HINTS.TXT" file available on the install CD/DVD (or from your favourite mirror).
 
Old 04-02-2008, 09:58 AM   #5
stu_mueller
Member
 
Registered: Aug 2006
Location: England
Distribution: Slackware, Zenwalk
Posts: 114

Original Poster
Rep: Reputation: 15
Unhappy

Quote:
Originally Posted by Calidore View Post
As you said yourelf huge kernel is usualy only used for installs. After install you change it to generic one or recompile your own, well atleast that's what i do anyway.
There is no problem using the huge kernel if you want. but if you use the generic one or recompile your own the footprint of the kernel will be much smaller and you can free up some of the memory.
You can copy over your .config but dont forget to run "make oldconfig" (im not sure if this it the right command ).
I usualy delete the modules directory when recompiling my own kernel.
You say that you delete you modules when compiling a new kernel, however doesn't that mean that if you need to boot with your old kernel, hte modules that that kernel uses will no longer be there.

Am I safe to just leave the existing kernel and modules where they are, and compile a new one and its modules in parallel, and then reference the new kernel in lilo.conf, then if there is a problem with my new kernel I can still get in with the old one? Its really the modules that are worrying me!?!

And is the .config file for the hugesmp kernel in /boot ?

Stuart
 
Old 04-02-2008, 10:03 PM   #6
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
stu_mueller, yes that's definitely possible. I never delete the old modules when I compile a new kernel just in case I screw it up. However, if you are compiling an identical kernel version, (ie if you are recompiling 2.6.21.5 instead of a newer kernel version), then the modules directory located in /lib/modules may be overwritten. If you are compiling a DIFFERENT kernel version you don't need to worry in the slightest (unless you build multiple versions of that kernel), but otherwise you should change the CONFIG_LOCALVERSION value in your kernel build. See this thread for details (posts number 10 and 12 are very helpful): http://www.linuxquestions.org/questi...ules+overwrite

That will ensure that the modules directory is not overwritten -- it will put them in a new folder in /lib/modules that has the value of CONFIG_LOCALVERSION appended. Note that I may be providing slightly incorrect information here since I've never had to use this option (I don't usually recompile the default Slackware kernels and just wait for a new kernel release before compiling), but the idea at least is correct (read the linked thread for more info). I think it's a good idea to always keep the default kernels and modules around just in case something happens, since they are basically guaranteed to work.

[edit]And yes, the .config file for the huge-smp kernel is in /boot, but is called /boot/config-huge-smp-2.6.21.5-smp[/edit]
 
Old 04-03-2008, 03:28 AM   #7
stu_mueller
Member
 
Registered: Aug 2006
Location: England
Distribution: Slackware, Zenwalk
Posts: 114

Original Poster
Rep: Reputation: 15
Thanks for that. one finally thing, (I think) if you use the generic kernels you need to configure an initrd. I presume because they don't have the file systems built in.

If I am compiling my own kernel I can build the filesystem support into the kernel and not bother with an initrd, correct?

Why wouldn't they build the filesystems into the kernel in the generic kernels, is that not just making it harder?
 
Old 04-03-2008, 04:12 AM   #8
tommcd
Senior Member
 
Registered: Jun 2006
Location: Philadelphia PA USA
Distribution: Lubuntu, Slackware
Posts: 2,230

Rep: Reputation: 288Reputation: 288Reputation: 288
Quote:
Originally Posted by stu_mueller View Post
If I am compiling my own kernel I can build the filesystem support into the kernel and not bother with an initrd, correct?

Why wouldn't they build the filesystems into the kernel in the generic kernels, is that not just making it harder?
Yes, if you build the file system support into the kernel (select "y" for built in, not "m" for as a module) you won't need an initrd.
I'm not at my Slackware box now, but I think if you read the readme in the /boot directory about how to create an intitrd, I think Pat explains why file system support is not built into the generic kernels. I know I read it somewhere, just can't remember exactly where atm.
 
Old 04-03-2008, 06:14 AM   #9
stu_mueller
Member
 
Registered: Aug 2006
Location: England
Distribution: Slackware, Zenwalk
Posts: 114

Original Poster
Rep: Reputation: 15
OK this really is the finally question before I make the plunge and recompile my kernel

I would prefer to use 'make menuconfig' when choosing the options, but will this pick up my .config file?

Alien Bobs guide to compiling a kernel says to use 'make oldconfig', and doesn't mention 'make menuconfig'

do I use 'make oldconfig' to import the .config file and then 'make menuconfig'? or do I just use 'make oldconfig' and cannot use 'make menuconfig' if I have a .config file?
 
Old 04-03-2008, 06:17 AM   #10
zoran119
Member
 
Registered: Dec 2007
Posts: 217

Rep: Reputation: 18
I have just changed my kernel from huge-smp to generic-smp. I have also made /etc/rc.d/rc.wireless NOT executable (don't need it) and the improvement in the boot time is from 1m25s to 1m20s. A bit sad really. What can I do to speed it up a bit?

Code:
[rc.d]# find . -perm /o=x -maxdepth 1           
.
./rc.K
./rc.sysvinit
./rc.pcmcia
./rc.messagebus
./rc.vboxdrv
./rc5.d
./rc.font.new
./rc.acpid
./rc.M
./rc.6
./rc1.d
./rc.vboxnet
./rc.alsa
./rc.nfsd
./init.d
./rc0.d
./rc.inetd
./rc.sshd
./rc.inet1
./rc.syslog
./rc.gpm
./rc.0
./rc.local
./rc.yp
./rc.hald
./rc.modules-2.6.21.5-smp
./rc.inet2
./rc.samba
./rc6.d
./rc.4
./rc2.d
./rc3.d
./rc4.d
./rc.modules
./rc.S
./rc.modules-2.6.21.5
./rc.udev
 
Old 04-03-2008, 09:43 AM   #11
nekkutta
LQ Newbie
 
Registered: Feb 2008
Distribution: Slackware 12
Posts: 22

Rep: Reputation: 15
I'm working at recompiling my kernel right now, and stu_mueller, I believe that menuconfig will work as long as you copy the config file from /boot to .config at least it seemed to work for me... I've got a question though, what individual would be crazy enough to use 'make randconfig'???? that just looks like a disaster waiting to happen...

well, just waiting for my compiling to finish (PII 350MHz) ie. detached screen session haven't tried compiling a kernel since slack 10.2, and I gave up because either I messed something up or I just didn't have a clue of what I was doing. but I ended up with no sound, so I stuck with the default kernel then.

wish me luck.
nekkutta
 
Old 04-03-2008, 10:28 AM   #12
stu_mueller
Member
 
Registered: Aug 2006
Location: England
Distribution: Slackware, Zenwalk
Posts: 114

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by nekkutta View Post
haven't tried compiling a kernel since slack 10.2, and I gave up because either I messed something up or I just didn't have a clue of what I was doing. but I ended up with no sound, so I stuck with the default kernel then.
Same goes for me, i tried it on a slack 11 machine, and ended up with no sound. The how tos make it sound so easy... I'll give it a go tonight, and will probably have to reinstall the night after
 
Old 04-03-2008, 06:12 PM   #13
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,298

Rep: Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722Reputation: 722
stu_mueller, I know you finished your kernel (from the other thread you created), but for future reference `make menuconfig` works perfectly with an existing .config file allowing customization based on that .config file. You generally use `make oldconfig` when you have already setup your .config from a previous kernel version and want to compile a (slightly) newer version. Since you can't show only the new options in `make menuconfig`, it would be difficult and laborious to search through all of the options looking only for the new changes (since presumably you won't need to change any of the old stuff). Therefore, using `make oldconfig` shows only the new kernel options so you can decide what to do with them. I usually use `make oldconfig` to setup a new .config file since I've already created a nice, working .config for previous kernel versions. However, I usually use `make menuconfig` to check my kernel options afterward to make sure everything went ok. menuconfig is nicely branched, but oldconfig attempts to implement a branched structure in a linear question-asking format, which can be annoying and confusing. So I usually just check that I didn't cut off any whole branches of options by accidentally answering 'n' to the wrong option from oldconfig by checking the .config with menuconfig. (Confusing enough?)

zoran119, don't expect much of a bootup improvement just from switching kernels. You could try compiling a kernel that includes only options suited for your hardware, which might improve bootup time a BIT, but it won't be noticeable enough. I usually stick with the generic kernel until a new kernel version comes out -- I like to stay current with my kernel, so I compile my own, but I don't just recompile the default kernel because it really doesn't save that much time. As for improving bootup speed, the best thing you can do is disable services that you won't use. If you don't use ssh (or won't use it as a server, anyway), remove the executable bit on /etc/rc.d/rc.sshd. Likewise with the other options. Other than that, you're basically stuck.

nekkutta, I agree with you about the `make randconfig` option. I think it's mainly a testing feature to see if a randomly generated .config file can cause the compilation to fail (ie it's designed to track down possible warnings and build errors). As for the sound problem in your previous attempt, I wish you better luck this time. Problems like that can usually be recovered from playing with other sound options (or by googling your specific sound card). I like to check what modules are detected for my hardware using the generic kernel BEFORE compiling a custom kernel so I know what hardware-specific modules to enable.
 
Old 04-04-2008, 12:35 AM   #14
tommcd
Senior Member
 
Registered: Jun 2006
Location: Philadelphia PA USA
Distribution: Lubuntu, Slackware
Posts: 2,230

Rep: Reputation: 288Reputation: 288Reputation: 288
Stu and Nekkutta,
If you haven't seen this yet, here is a great reference for compiling your kernel. The whole book is available online here:
http://www.kroah.com/lkn/
 
Old 04-15-2008, 09:11 AM   #15
Exeunt
LQ Newbie
 
Registered: Feb 2007
Location: Horsham, PA
Distribution: Slackware 12.2, 14, Current
Posts: 18

Rep: Reputation: 1
Recompiling Kernels

Hi Guys,

I used to re-compile kernels and strip everything I could.

However, I have found over the years that there is a great advantage
to use the kernel from the install CD.

That is that when something goes wrong and your box won't boot, it's
very nice to boot from the install CD with a parameter like "root=xxxx",
and boot into the real filesystem with the correct modules.

I have had everything go wrong that can, and this is why I don't
re-compile kernels again.

Exeunt
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Huge.s V.S hugesmp.s Denisius Slackware 13 11-04-2007 02:41 PM
Where does the hugesmp.s kernel go? NightSky Linux - Newbie 3 08-18-2007 10:11 PM
problems with hugesmp.s nelsonslament Slackware - Installation 2 07-31-2007 10:05 PM


All times are GMT -5. The time now is 01:19 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration