lkml.org 
[lkml]   [1998]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: F00F... (And Cyrix/K6/..)
On Thu, 3 Sep 1998, David Whysong wrote:

> > I guess it's just the code that gives the values in /proc thats
> > buggy .... well, sorry but I'm missing the time for a closer look.

> Earlier I reported that the f00f workaround was not enabled on my
> computer. I was partly in error. A few minutes ago, after unmounting my
> disks, I did this:

> [root@Sleepy /root]# ./f00f
> Illegal Instruction
> [root@Sleepy /root]# ./f00f
> [machine hangs]

Hrm. I didn't try my test twice. I can't check right now. (busy at work,
wouldn't do to reboot my machine at will right now ;-)
From looking at the code i dont know how this could happen, but maybe I just
couldn't find the right piece of code. Anyone, upon triggering the f00f bug,
the kernel catches it, does it need to reinstate the fix, and does it check
for current_cpu_data.f00f_bug in such a case ?

> I think there is a real problem with the f00f workaround in recent
> kernels.

Not just with the f00f workaround, with the entire 'check_bugs()' function,
including the Cyrix detection, for instance. The problem is that since
2.1.115 or thereabouts, when compiling with SMP, 'smp_init()' is called
before check_bugs(). Apparently this is necessary for SMP P5 boards to work,
but it also brings up this problem.

check_bugs() operates on boot_cpu_data, a single struct cpuinfo_x86. SMP
uses an array of those structs, _and uses boot_cpu_data to initialize them
all_, including the boot cpu itself. But the boot_cpu_data struct isn't
filled yet, it misses the checks from check_bugs, which also checks for hlt,
fpu and AMD K6 and Cyrix processors, amongst other things. So every piece of
code which uses 'current_cpu_data' instead of 'boot_cpu_data' (which is
everything, I should think) gets 'outdated' info.

According to Thomas Bogendoerfer, SMP for P5's needs the vector interrupt
table readonly, and smp_init doesn't like that. I dont know much about
kernel internals or ia32, but having SMP P5's not F00F protected sounds
weird, not to mention having every other bug in every other SMP kernel
lurking undetected ;-) Could whoever maintains this kind of code (Linus,
from MAINTANERS ?) change it so that either check_bugs() is incorporated in
smp_init, so it can order the bugchecks itself, or make
check_bugs_cpu(struct cpuinfo_x86) that gets called by smp_init for each
processor. (yuck ;-)

I wouldn't mind doing it at all, but i dont have the foggiest clue about
what the functions do, so I dont think it's a good idea. I will if noone
else does it, though.

Thomas.


-
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/faq.html

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.832 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site