Messages in this thread | | | Date | Fri, 4 Sep 1998 14:25:10 +0200 (CEST) | From | Thomas Wouters <> | Subject | Re: 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
| |