Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: 2.2.0pre1 OOPS on boot. | Date | 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/
| |