Yesterday, I downloaded all the discs for Slack 11.0, and prepared to
install it on a Compaq ProLiant 6400R.

This box has quad Xeon 500/100 processors with 2MB cache (I have
another box with quad 550/100 1MB cache as well), Compaq Smart Array
Controller 3200 ("SMART2/P" family) with a RAID5+spare config, plus
two NICs - an AceNIC gigabit, and a dual eepro100.

The default raid.s kernel seems to work alright, but of course isn't
SMP. I'm sorta missing a bunch without SMP enabled.

So, I go about configuring a new kernel with (what I thought were)
just the right things, but that crashes on load (with so much stuff
filling the screen that I can't quite make out what component failed).

Fine. take the config file from the raid.s kernel, and use that on a
cleaned ('make mrproper') kernel build, and tweak it to only add SMP
and 4 processor support (via 'make menuconfig; make dep; make bzImage;
(revert to root, make install, move files to where they need to be,
lilo). The system still crashes - but I determine it's apparently got
to do one of the NIC drivers (ifconfig is blowing chunks), so I pull
both of the NICs and restart.

It then looks promising, but hands on the hotplug start. I reboot to
the plain raid kernel, and rename the rc.hotplug file to temporarily
disable it. I reboot (stil lwithout NICs), and it seems to load up
okay. It's sitting off in the workarea now idling away, where it will
remain until I have some feedback or discover something in my readings
to give me hope of a solution.

So, the question: what special hoops do I need to jump through to deal
with adding SMP to the kernel build? Ideally, I'd like to strip out a
bunch of other junk (a LOT of SCSI cards that aren't part of my
config, streamline some stuff like removing PCMCIA because this isn't
a laptop and I don't have any intention of stuffing an interface in
there, etc). However, basically, I'd like to add SMP to the the
existing RAID kernel config (which supports both NICs).

Any pointers?

FYI - this is intended to be a dns/web/mail/file server, not a
workstation. so there's no sound, no X, etc.

On Sun, 17 Dec 2006 21:51:03 -0800, "Sean Straw (to email, replace lutefisk with mail)" <usenet@lutefisk.professional.org> wrote:

>So, I go about configuring a new kernel with (what I thought were)
>just the right things, but that crashes on load (with so much stuff
>filling the screen that I can't quite make out what component failed).
>
>Fine. take the config file from the raid.s kernel, and use that on a
>cleaned ('make mrproper') kernel build, and tweak it to only add SMP
>and 4 processor support (via 'make menuconfig; make dep; make bzImage;

'make mrproper' deletes the .config, so you need to copy the .config
over after doing the make mrproper, then add the SMP support with 'make
menuconfig' and so on...

Grant.
--
http://bugsplatter.mine.nu/

> Fine. take the config file from the raid.s kernel, and use that on a
> cleaned ('make mrproper') kernel build, and tweak it to only add SMP
> and 4 processor support (via 'make menuconfig; make dep; make bzImage;
> (revert to root, make install, move files to where they need to be,
> lilo). The system still crashes

The system probably crashes because you are loading non-SMP modules into
an SMP kernel. It is not enough to install an SMP kernel, you will also
have to do "make modules; make modules_install".

I don't know how much more work is involved in Slackware 11. With
Slackware 9.1 I also needed to compile some extra modules as the ALSA
modules and XFree86 drm modules were not part of the kernel source.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

On Mon, 18 Dec 2006 16:59:12 +1100, Grant <g_r_a_n_t_@dodo.com.au>
wrote:

>On Sun, 17 Dec 2006 21:51:03 -0800, "Sean Straw (to email, replace lutefisk with mail)" <usenet@lutefisk.professional.org> wrote:

>>Fine. take the config file from the raid.s kernel, and use that on a
>>cleaned ('make mrproper') kernel build, and tweak it to only add SMP
>>and 4 processor support (via 'make menuconfig; make dep; make bzImage;
>
>'make mrproper' deletes the .config, so you need to copy the .config
>over after doing the make mrproper, then add the SMP support with 'make
>menuconfig' and so on...

Sorry if I was unclear - I was adding the raid config file to a
previously cleaned kernel source tree, then running make menuconfig,
etc.

Henrik's response is in all likelyhood the key bit I'm searching for.

On Mon, 18 Dec 2006 08:27:59 +0100, Henrik Carlqvist
<Henrik.Carlqvist@deadspam.com> wrote:

>> Fine. take the config file from the raid.s kernel, and use that on a
>> cleaned ('make mrproper') kernel build, and tweak it to only add SMP
>> and 4 processor support (via 'make menuconfig; make dep; make bzImage;
>> (revert to root, make install, move files to where they need to be,
>> lilo). The system still crashes
>
>The system probably crashes because you are loading non-SMP modules into
>an SMP kernel. It is not enough to install an SMP kernel, you will also
>have to do "make modules; make modules_install".

Okay, so I should definatley rename the kernel source tree when
building the SMP version so that the modules_install uses a different
target for the installation of those modules (i.e. leaving me with a
functioning set of single-processor drivers for fallback), right?

>I don't know how much more work is involved in Slackware 11. With
>Slackware 9.1 I also needed to compile some extra modules as the ALSA
>modules and XFree86 drm modules were not part of the kernel source.

Fortunatley, as this is a console server config, not an X workstation,
most of that type of stuff doesn't apply here.

Thank you very much for the assist - I kept thinking I'd selected the
wrong kernel options when I'd first streamlined the kernel to
eliminate unnecessary stuff, and each of those kernel builds was long
because the system wasn't running with an SMP kernel, so it wasn't
taking advantage of all the (relative) CPU horsepower available.

Sean Straw (to email, replace lutefisk with mail) wrote:
> Okay, so I should definatley rename the kernel source tree when
> building the SMP version so that the modules_install uses a different
> target for the installation of those modules (i.e. leaving me with a
> functioning set of single-processor drivers for fallback), right?

No the name of the source tree doesn't matter.
It's in one of the configuration menus.

Under "General setup" the first item:
"Local version - append to kernel release".


Regards,

Kees.

--
Kees Theunissen.

On Mon, 18 Dec 2006 19:43:47 +0100, Kees Theunissen <theuniss@rijnh.nl> wrote:

>Sean Straw (to email, replace lutefisk with mail) wrote:
>> Okay, so I should definatley rename the kernel source tree when
>> building the SMP version so that the modules_install uses a different
>> target for the installation of those modules (i.e. leaving me with a
>> functioning set of single-processor drivers for fallback), right?
>
>No the name of the source tree doesn't matter.
>It's in one of the configuration menus.
>
>Under "General setup" the first item:
>"Local version - append to kernel release".

Not with 2.4.33 One modifies EXTRAVERSION in the top level Makefile.

Grant.
--
http://bugsplatter.mine.nu/

"Sean Straw (to email, replace lutefisk with mail)"
> Okay, so I should definatley rename the kernel source tree when
> building the SMP version so that the modules_install uses a different
> target for the installation of those modules (i.e. leaving me with a
> functioning set of single-processor drivers for fallback), right?

Having both SMP and non-SMP modules installed sounds like a good idea to
me even though I haven't done so myself. I simply overwrote the original
non-SMP modules. There are also other kernel options that make modules
mismatch with different kernels. One other such option is the HIGHMEM
option. There have been other answers describing how to get different
names for the module directory tree.

In my experience it is safest to replace the modules when the kernel is
replaced with a differently configured kernel. Only a few weeks ago I
recompiled a 2.6 kernel to add support for linux security modules.
Unfortunately that caused my old custom modules to fail, on that system I
had patched modules for via unichrome drm and xvmc. Once again I had to
rebuild those custom modules.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

On Tue, 19 Dec 2006 00:39:07 +0100, Henrik Carlqvist
<Henrik.Carlqvist@deadspam.com> wrote:

>Having both SMP and non-SMP modules installed sounds like a good idea to
>me even though I haven't done so myself.

For me, it's having a fallback kernel.

>In my experience it is safest to replace the modules when the kernel is
>replaced with a differently configured kernel. Only a few weeks ago I
>recompiled a 2.6 kernel to add support for linux security modules.
>Unfortunately that caused my old custom modules to fail, on that system I
>had patched modules for via unichrome drm and xvmc. Once again I had to
>rebuild those custom modules.

Which is the point of using a different suffix, thus allowing more
than one kernel to co-exist. Plus, if you're running from a different
kernel version (options = new suffix), then the modules for the one
won't be accessible to the other in the natural course of booting, so
patched modules wouldn't be there unless you re-patched them...

I've had a busy few years, so it's been a while since I configured a
new host to run multiple kernels. I'll be doing a lot of reconfig in
the coming weeks to get these boxes sorted to port some older systems
over to.

Thanks for the assist, the new streamlined RAID+SMP kernel is booting
nicely (with NICs reinstalled <g>), and is smaller than the
out-of-the-box raid kernel, since it doesn't have a bunch of
unnecessary cruft coming along for the ride.