Messages in this thread |  | | Date | Sat, 6 Feb 1999 13:56:45 -0500 (EST) | | From | Rafael Reilova <> | | Subject | Re: Bugs in x86 boot sequence? |
| |
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/
|  |