> Well, then will you please remove the f00f bugfix as well
> and develop a user space tool to switch it on?
> (The sarcastic taste was intended. :-))
> IMHO the processor bug workarounds should be in the
> the kernel.
I personally feel that all the (reasonably small) CPU workarounds should be
in the kernel, but I seem to have lost that battle. The idea that all the
distributions are going to include start-up scripts which grep /proc/cpuinfo
and run set6x86 accordingly is ludicrous wishful thinking IMHO.
To address your first point, I think the f00f bugfix has to be kernel space.
It seems to mess with mm things (does this indicate how little I understand
about it? :)
> And if the bugfix itself causes the file corruption then
> no matter where you enable the bugfix and which tool you use...
Note that there are two different techniques for working around the bug:
- set the NO_LOCK bit in CR<whatever>; can cause problems in obscure
circumstances (Alan mentioned a graphics / accelerator card problem)
- do some undocumented magic provided by (or reverse engineered from)
Cyrix, that seems to modify the CPU behaviour when executing the
offending instruction, making to do a noop afterwards. I don't know
of any problems caused by this.
-- %DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears- 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/