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
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? :-(
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...
Regards,
Richard....
processor : 0
vendor_id : CyrixInstead
cpu family : 5
model : 2
model name : 6x86 2x Core/Bus Clock
stepping : 5
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu
bogomips : 99.94
-
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/