I'm still learning about my new box and hardware. Because I have so much to learn, I have been using the stock 2.6.21.5 huge kernel that came with Slackware 12. Recently I recompiled that same kernel with some modest changes, such as support for lm-sensors. When I run this new kernel the boot screen is abnormal. The dual penguins are stretched and skinny and the screen output text is tiny. I cannot see the bottom of the screen display.

My boot configuration calls for VGA=788, which looks beautiful with the stock huge kernel but not with my compiled version. Seems that nothing I do with the VGA setting changes the screen output, everything remains tiny and stretched. Similarly, if I choose a non framebuffer VGA boot parameter (for example, VGA=3), everything stays the same resolution.

I compared my kernel configuration file to the stock huge kernel and found nothing obvious. Any thoughts where I should troubleshoot is appreciated.

After spending the day tweaking various aspects of my new box, and trying different kernel options, I discovered the cause of my problem as originally posted. I booted with the stock huge kernel and then saved a copy of dmesg. I then booted with my recompiled kernel and saved that dmesg. I noticed two interesting differences:

stock huge kernel:
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device

my custom kernel:
fb1: VESA VGA frame buffer device

I then used Kompare to diff the stock huge kernel config file with my config file. I found two suspects:

stock huge kernel:
CONFIG_FB_DDC=m
CONFIG_FB_NVIDIA=m

my custom kernel:
CONFIG_FB_DDC=y
CONFIG_FB_NVIDIA=y

I modified my kernel for module support. The kernel then booted with an expected normal screen and fat penguins. I don't pretend to understand the underlying root cause, although I am using the on-board nvidia video chip rather than a separate nvidia video card.

During my journey this afternoon, I ran across a thread about using both cores of a dual core processor to speed compile times. I use a script I wrote to automate most of my compiling and I added "-j4" to my make commands. Watching gkrellm told me that both CPU cores finally were being used. My compile time went from a half hour (a dramatic improvement over my 3+ hours with my old box) to about 15 minutes. Sweet.

I noticed a kernel option called CONFIG_NR_CPUS and the default is 32. I changed that to 2 as that is all the cores in my BE-2400 CPU. I don't know whether that will make any difference anywhere.

I noticed an option to modify the console scroll buffer (CONFIG_VGACON_SOFT_SCROLLBACK_SIZE). I changed that option from the default of 64KB to 256KB.

I hope this information helps future inquiries.

Question:
In my rc.modules script I enabled the modprobe acpi-cpufreq option. I always receive an error message of FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.21.5/kernel/arch/i386/cpu/cpufreq/acpi-cpufreq.ko) no such device. The module does exist. I modified the CPU type in my kernel configuration from the stock huge kernel Pentium Pro to MK8, as my CPU is a member of the K8 family (BE-2400). I still receive this error message. Any help is appreciated.

I'm assuming that you didn't have a suffix to your kernel name when you compiled it (similar to the "-smp" in stock kernels), so that means you probably clobbered all you modules from your stock kernel. Either that or you never installed the new modules for your current kernel. Are you sure you built that modules for your current kernel? Check your config and report back your steps in building the kernel and modules (just show what commands you used).

No I did not use a suffix --- and I did not clobber my existing modules . The stock huge kernel uses the "smp" suffix and the modules use the same suffix. I did not touch those modules or kernel because during compile testing I always need an escape route to reboot and recover from possible mistakes.

When I compile and test a new kernel I create an additional boot option so I can run the stock kernel and modules or my new kernel and modules. The two environments remain separate.

My compiled kernel and modules are simply 2.6.21.5 with no suffix. I also use a separate rc.modules-2.6.21.5 to keep the rc.modules-2.6.21.5-smp clean.

I also enabled the following in rc.modules and receive no errors:

/sbin/modprobe powernow-k8
/sbin/modprobe cpufreq_powersave
/sbin/modprobe cpufreq_ondemand
/sbin/modprobe cpufreq_conservative

Checking with lsmod shows those four modules are running.

Everything in the new kernel works wonderfully except for that one error message.

acpi-cpufreq is a generic module. You have already loaded the correct module which is powernow-k8. Comment the apci-cpufreq module as it is not needed.

Well alrighty then! Thank you!

If you didn't add a suffix, wouldn't your custom kernel's modules and the old smp's modules be installed in the same directory ?

what does ls /lib/modules show ?

No because the original stock smp kernel has an "-smp" suffix but his custom kernel is not smp and does not have a suffix. However, if he decided to use any of the non-smp stock kernels then he might run into issues.