Re: Bugs in x86 boot sequence?

Rafael Reilova (rreilova@ececs.uc.edu)
Sat, 6 Feb 1999 13:56:45 -0500 (EST)


Hi Richard,

I agree with you completely, the cpu detection sequence should be
completely overhauled for 2.3. I think that it should happen at a much
earlier point. Doing so would avoid the dodgy_tsc hack below, and the
recalibration of bogomips. I think the main problem for not doing so has
to do with SMP setup. If given a chance I would put the cpu detection
right after the printk(linux_banner) ;-)

On Sat, 6 Feb 1999, Richard Gooch wrote:

> Hi, all. I've just noticed a couple of potential problems in the x86
> boot sequence:
>
> 1) dodgy_tsc() is supposed to call cyrix_model() for Cyrix CPUs. But
> first it calls get_cpu_vendor() which sets the vendor code to 0xff
> (on my 6x86 anyway: /proc/cpuinfo appended). The result is that
> cyrix_model() is not called at this point, so the TSC capability
> flag can't be cleared

There shouldn't be any TSC cap. flag to be cleared anyways, on a 686.
Your cpuinfo is correct for a 686 clasic, only the fpu flag should be
there (and it is!).

Now the dodge_tsc *is* an ugly hack without a simple soln. IIRC, the
problem is that MediaGX reports a TSC that is not there (so it crashes and
burns), but since setup_time(), et al. code runs before the cpu is
properly identified, it assumes that the capabilities read in head.S are
correct! Still calling the same setup routine twice is a dirty hack in my
book. You can argue that this is Cyrix fault, but in the end people still
want to use their chips with Linux.

> 2) check_bugs() calls identify_cpu() before check_cx686_cpuid() is
> called. Unfortunately, check_cx686_cpuid() initialises the
> capability bitmask using cpuid(), which means that capabilities
> set in cyrix_model() (called from identify_cpu()) are blown away.
> Perhaps the answer is to add extra capabilities after
> check_cx686_cpuid(), or perhaps it should be moved after
> identify_cpu()? But then moving it may cause problems? :-(

What extra-capabilites are you talking about? What cpuid returns is all
there is.

The convoluted part of check_cx*() is my bad. The cosmetic fix is simple
though, do the calls to the check_cx*() functions from within
cyrix_model(). At the time I was just trying to be consistent with the
rest of the bugs.h code.

Anyways, check_cx686_cpuid() checks that the processor is actually a
686(L,MX,MII) so it *will* read the right capabilities. The problem is
that some braindead motherboard BIOS disable the cpuid inst. on Cyrixes
686MX & MII's, plus the 686(L) have it off by default. So this hack is a
must have.

>
> Does anyone have any comments on these points? Am I missing something
> deep and/or subtle?
>
> I find the whole x86 boot sequence pretty convoluted, with some
> functions being called more than once and from different places. It
> feels like a cleanup is needed: I'm having visions of a certain pasta
> dish...

Yep it is convoluted. It is a myriad of undocumented interactions that
somehow make it work right, and it is extremely fragile...

Cheers,

Rafael

-
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/