Maybe Alan Cox can be convinced this time with _proper_ information.
(At least it seemed so in his mail.)
> distributions are going to include start-up scripts which grep /proc/cpuinfo
> and run set6x86 accordingly is ludicrous wishful thinking IMHO.
Well, I think that the proper approach is that everything that controls
processor behaviour belongs to the kernel. Just an example: someone
complained to me that he set ARRs with set6x86 and /proc/mtrr did not
reflect the changes...
> 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? :)
It changes the interrupt descriptor table layout, as far as I understand
it.
And I said it only for fairness. :-)
> > 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)
To repeat myself: this crept into linux-2.2.8, ...
> - 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.
... and this is already in 2.2.10. Don't you guys read the code others
write?
:-(
Best regards,
Zoltan Boszormenyi
-- Microsoft: It's where you don't want to go today.- 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/