Since nobody else has reported this bug, I thought I'd hunt it down
and isolate the problem, which seems to be that the "rdmsr" and
"wrmsr" assembler instructions were replaced by ".byte 0x0f,0x32" and
".byte 0x0f,0x30". I'm not sure what 2.0.26 was attempting to fix in
time.c; perhaps another test can be made to decide which of the two
methods to use???
I'm including, for reference, (A) a small patch (applied to 2.0.26+)
to undo the problem, and (B) output from /proc/cpuinfo in case this is
specific to the Intel 586 in the box.
______________________________________________________________________________
Kristofer Karas - Sr Clinical Sys Admin - Beth Israel Deaconess Medical Center
mailto:ktk@ktk.bidmc.harvard.edu http://ktk.bidmc.harvard.edu/~ktk/
AMA/CCS, DoD, RF900RR, HawkGT, !car - Will design LISP machines for food :-)
"The person who risks nothing, is nothing, has nothing,
does nothing, and becomes nothing." - Leo Buscaglia
------------------------------------------------------------------------------
Output of /proc/cpuinfo:
processor : 0
cpu : 586
model : Pentium 75+
vendor_id : GenuineIntel
stepping : 5
fdiv_bug : no
hlt_bug : no
fpu : yes
fpu_exception : yes
cpuid : yes
wp : yes
flags : fpu vme de pse tsc msr mce cx8
bogomips : 35.84
And the patch to reverse 2.0.26 for time.c in arch/i386/kernel/:
--- time.c.buggy Thu Dec 5 16:13:10 1996
+++ time.c Thu Dec 5 16:13:38 1996
@@ -471,9 +471,9 @@
if( x86_model == 0 ) {
/* turn on cycle counters during power down */
__asm__ __volatile__ (" movl $0x83, %%ecx \n \
- .byte 0x0f,0x32 \n \
+ rdmsr \n \
orl $1,%%eax \n \
- .byte 0x0f,0x30 \n "
+ wrmsr \n "
: : : "ax", "cx", "dx" );
udelay(500);
}