Is the kernel source in 12.1 the smp-huge kernel?

nonis · 05-25-2008, 10:45 PM

Is the kernel in /usr/src/linux configured as the smp-huge kernel that comes with slackware?

T3slider · 05-25-2008, 11:28 PM

Quote:

Originally Posted by nonis

Is the kernel in /usr/src/linux configured as the smp-huge kernel that comes with slackware?

Try typing the following:

Code:

$ diff /usr/src/linux-2.6.24.5/.config /boot/config-huge-smp-2.6.24.5-smp
$ diff /usr/src/linux-2.6.24.5/.config /boot/config-generic-smp-2.6.24.5-smp

At least on my system it corresponds to the generic-smp configuration. It is definitely recommended to use the generic-smp kernel:

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT

Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.

Quote:

Originally Posted by CHANGES_AND_HINTS.TXT

As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels; the huge kernels are primarily intended as
"installer" and "emergency" kernels in case you forget to make an initrd.
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 are configured for
SMP usage, so you won't have to modify those to build external modules
(such as NVidia or ATI proprietary drivers) if you use the SMP kernel.

If you decide to use one of the non-SMP kernels, you will need to follow the
instructions in /extra/linux-2.6.24.5-nosmp-sdk/README.TXT to modify your
kernel sources for non-SMP usage. Note that this only applies if you are
using the Slackware-provided non-SMP kernel - if you build a custom kernel,
the symlinks at /lib/modules/$(uname -r)/{build,source} will point to the
correct kernel source so long as you don't (re)move it.

If you decide to use one of the huge kernels anyway, you will 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.

If you DO decide to use the huge-smp kernel (I would discourage it, but it can be OK -- although you may have to blacklist some modules in /etc/modprobe.d/blacklist if you are having any troubles), you won't have trouble using the standard .config in /usr/src/linux-2.6.24.5 though. If you use one of the non-SMP kernels, however, you WILL have trouble. In that case, you must convert the sources to non-SMP, as explained in extra/linux-2.6.24.5-nosmp-sdk/README.TXT:

Quote:

Originally Posted by extra/linux-2.6.24.5-nosmp-sdk/README.TXT

By default, the kernel in Slackware supports SMP. With as common as
multicore CPUs and SMP boards have become, this seems like the
obvious choice. The kernels are probably better for single CPU
machines, too, if they will run them.

If you have to use one of the non SMP kernels (huge.s or generic.s),
then you will need to reconfigure your kernel sources to build any
additional kernel modules. In order to compile outside kernel
modules and such, you *may* need to install non-SMP kernel-headers
(we're not entirely sure about this), and either build the kernel once
without SMP (which might take a while), or apply a patch to freshly
installed kernel sources to convert them from smp to non-SMP
(this is fast).

To switch your unmodified Slackware kernel sources from SMP to non-SMP,
run the following script in this directory:

./patch-to-non-smp.sh

If you'd rather apply these patches by hand, feel free.

At this point if you are running huge.s or generic.s, you should have
no problems building kernel modules. This has been tested here with the
latest nVidia X.Org drivers.

nonis · 05-25-2008, 11:57 PM

Well, my system is running fine, but I need to enable high resolution timers in the kernel. I want to keep it the same but enable that. I was just wondering what the current settings are in the kernel source.

Strange, I don't remember deciding in the install to use the huge kernel, but my vmlinuz link in /boot points to the huge kernel. I'll try changing it to the generic before I recompile my kernel, because I don't want to break anything.

On a side note, what does vmlinuz mean? It seems like it should be linux...

T3slider · 05-26-2008, 12:13 AM

Quote:

Originally Posted by nonis

Strange, I don't remember deciding in the install to use the huge kernel, but my vmlinuz link in /boot points to the huge kernel. I'll try changing it to the generic before I recompile my kernel, because I don't want to break anything.

The huge-smp kernel is chosen by default during installation and you are expected to switch to the generic-smp kernel after the first boot (or if you're really good you can `chroot` before rebooting but after installing and switch to the generic-smp kernel then). Using the generic-smp kernel requires the use of an initrd (initial RAM disk), since the filesystems (and almost everything else) are compiled as modules and must be loaded before your system can boot. Read the /boot/README.initrd file to see how to make an initrd. Alien Bob also has a nice script that usually outputs a correct mkinitrd command here. After creating the initrd, you have to edit /etc/lilo.conf and add "initrd = /boot/initrd.gz" (assuming you stuck with the default naming of the initrd) to your boot stanza. The bottom part of my lilo.conf is posted below for a reference. Note that I included the huge-smp kernel as a secondary option in case the initrd is created improperly or in case anything ever happens -- you will be able to boot with that instead of having to use the install CD/DVD to boot.

Code:

image = /boot/vmlinuz-generic-smp-2.6.24.5-smp
  initrd = /boot/initrd.gz
  root = /dev/sda1
  label = Generic
  read-only  # Partitions should be mounted read-only for checking

image = /boot/vmlinuz-huge-smp-2.6.24.5-smp
  root = /dev/sda1
  label = Huge
  read-only

Note that you should change /dev/sda1 to point to the root (/) partition of your hard drive. Remember to run `lilo` after editing the file to write to the MBR.

Quote:

Originally Posted by nonis

On a side note, what does vmlinuz mean? It seems like it should be linux...

vmlinuz (or vmlinuz-huge-smp-2.6.24.5-smp etc.) is just the actual kernel image. The z at the end traditionally meant that the kernel image was compressed I think. See the wikipedia article for a little bit of info.

Quote:

Originally Posted by nonis

Well, my system is running fine, but I need to enable high resolution timers in the kernel. I want to keep it the same but enable that. I was just wondering what the current settings are in the kernel source.

As long as you know what you are doing that's fine. A nice kernel building guide, created by Alien Bob, is located here. Working from the generic-smp configuration should be fine (copy /boot/config-generic-smp-2.6.24.5-smp to /path/to/kernel/sources/.config and run `make menuconfig` and it should pick up the old file).

nonis · 05-26-2008, 12:13 AM

Well, I changed lilo.conf adding this:

image = /boot/vmlinuz-generic-smp-2.6.24.5-smp
root = /dev/sda2
label = Linux-generic
read-only
to try booting from the generic kernel, but it causes a kernel panic: Non Syncing VFS. It says something like "can not find any file system to mount root"

I just copied and pasted the lines from booting the other kernel, but changed the image. Then I ran lilo, and rebooted.

T3slider · 05-26-2008, 12:20 AM

See my post above. Looks like we posted at the same time.

nonis · 05-26-2008, 12:48 AM

yeah. Haha. Thanks for the help. Honestly, I've rebuilt the kernel and such before, but only on a system that my friend set up for me originally. He probably set up the first initrd for me. Thanks!