2004-11-07 19:08:45

by ledva

[permalink] [raw]
Subject: bugy config cpu 386 selection CONFIG_X86_TSC

Hi

I just had to compile kernel for zipslack for 386 because
it's default has some problem with *WP
I chose linux-2.4.27 tree.
Sure i did it on other machine:

processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 6
model name : AMD-K6tm w/ multimedia extensions
stepping : 2
flags : fpu vme de pse tsc msr mce cx8 mmx

I did

make mrproper && make menuconfig && \
make dep && make bzImage

selected 386 and several other options as you
can see in .config which can be obtained from
http://portal.promon.cz/ledvinka/i/tscerr/config

All changes were done entirely via menuconfig.
Result of booting up the kernel is:

CPU: 386
Kernel panic: Kernel compiled for Pentium+, requires TSC feature!
In idle task - not syncing

So i guess i just have to comment out
CONFIG_X86_TSC
that will be my first try.

Do not i have switch it for:
CONFIG_X86_TSC_DISABLE
Sounds like it is option for kernel
not to use TSC although it's present?

Please CC me. Words comment out OR switch should be enough ;-)


2004-11-07 21:07:27

by Mikael Pettersson

[permalink] [raw]
Subject: Re: bugy config cpu 386 selection CONFIG_X86_TSC

On Sun, 07 Nov 2004 20:07:45 +0100, <[email protected]> wrote:
>I just had to compile kernel for zipslack for 386 because
>it's default has some problem with *WP
>I chose linux-2.4.27 tree.
...
>I did
>
>make mrproper && make menuconfig && \
>make dep && make bzImage
>
>selected 386 and several other options as you
>can see in .config which can be obtained from
>http://portal.promon.cz/ledvinka/i/tscerr/config
>
>All changes were done entirely via menuconfig.
>Result of booting up the kernel is:
>
>CPU: 386
>Kernel panic: Kernel compiled for Pentium+, requires TSC feature!
>In idle task - not syncing

Your config still has CONFIG_X86_TSC set, hence the panic.

Do a 'make oldconfig' after switching CPU type from a
TSC-capable one to a TSC-less one in 2.4 kernels. There
is a known bug in the old configuration system where it
can leave derived options in an inconsistent state after
a single round of option changes. CONFIG_X86_TSC is the
prime example of this. Doing a second configuration round
allows the derived options to reach a fixpoint.