Re: 2.2.0pre1 OOPS on boot.

Linus Torvalds (torvalds@transmeta.com)
30 Dec 1998 01:59:25 GMT


In article <m0zurJp-0007U1C@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> On Tue, 29 Dec 1998, Alan Cox wrote:
>>
>> > Disable SMP. It oopses on boot with my Cyrix with SMP=1 too, while
>> > 2.1.132* is fine. It also crashes and burns on boot with a MediaGX (known
>> > bug).
>>
>> As an additional note to my report of this same problem earlier, SMP is
>> disabled on my system.
>
>Looks like its also CPU selection dependant. Im not quite sure what the
>person who updated time.c was on, possible too many penguin mints.

Ahh, one last-minute thing in the 2.2.0-pre timeframe was to make a few
more things depend statically on the CPU configuration.

In particular, the thing that probably bit you is that as of 2.2.0-pre1,
the CONFIG_M586 define implies that the target machine _has_ to support
the TSC. This was simply because the SMP scheduling code came to depend
on the TSC for certain things, and it's too timing critical to do other
than as a compile-time define.

As that meant that CONFIG_M586 had to imply a TSC when compiling for
SMP, it made no sense to not enforce that assumption in other places
too. That's notably "do_gettimeofday()".

There is very arguably a bug there, but I'd say that it's just lack of
documentation. I've now documented that CONFIG_M586 implies having a
TSC, and made the bootup bug-check code actually verify that the runtime
configuration matches what the kernel was compiled for and it should
just panic clearly when it encounters unsupported hardware.

So basically:

- CONFIG_M386: Runs on anything
- CONFIG_M486: requires "invlpg" and a working supervisor mode WP bit
- CONFIG_M586: requires "rdtsc"
- CONFIG_M686: requires a non-broken local APIC when running SMP

and now all machine configuration options actually have real meaning for
the behaviour of the kernel apart from just some alignment hints to the
compiler.

We may want to make these options more granular, there is no real reason
why they should be grouped by how intel happened to implement certain
things.

I'll make a 'test1-patch-2.2.0-pre2.gz' available shortly in case people
want to look at this,

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/