Looks like every time the CPU detection code is rewritten, the printing of the
CPU name for "pure" (i.e. "original") 386s suffer. Last time, the "\n" after
the "CPU: 386" line was missing.
This time it's worse. It's tripping the "unknown CPU" code path:
CPU: Before vendor init, caps: 00000000 00000000 00000000, vendor = 255
[...]
CPU: ff/00
and looking at /proc/cpuinfo:
processor : 0
vendor_id : unknown
cpu family : 3
model : 0
model name : ff/00
stepping : unknown
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : no
fpu_exception : no
cpuid level : -1
wp : no
flags :
bogomips : 3.62
Shouldn't the code be supposed to figure that, since there is no cpuid, it
should be a 386 or an early 486?
I think that table_lookup_model in arch/i386/kernel/setup.c should code a
vendor of 255 as a special case and return "386" or something like that instead
of bailing out. If everybody agrees, I'll make a patch for Linus.
--
Cesar Eduardo Barros
[email protected]
[email protected]
I've made a patch to fix the problem. I've not even compiled it yet (I might do
it later).
--- linux-2.4.2.orig/arch/i386/kernel/setup.c Tue Feb 27 10:17:18 2001
+++ linux-2.4.2/arch/i386/kernel/setup.c Tue Feb 27 11:04:54 2001
@@ -1996,6 +1996,15 @@
case X86_VENDOR_UNKNOWN:
default:
/* Not much we can do here... */
+ /* Check if at least it has cpuid */
+ if (c->cpuid_level == -1)
+ {
+ /* No cpuid. It must be an ancient CPU */
+ if (c->x86 == 4)
+ strcpy(c->x86_model_id, "486");
+ else if (c->x86 == 3)
+ strcpy(c->x86_model_id, "386");
+ }
break;
case X86_VENDOR_CYRIX:
--
Cesar Eduardo Barros
[email protected]
[email protected]