On Wed, 2 Oct 2002, Ralf Baechle wrote:
> > Here is a new version that takes your recent mips64 cache code rearrange
> > into account. OK to apply?
> I'm not sure if that's really a good idea. Technically it's ok but I expect
> users of the R4000 to missconfigure their kernels. So I wonder if it might
I plan to write some code to detect various processor bugs, including
this one. A nice kernel panic will instruct users how to configure the
kernel properly, so this is not an issue. If you want me to defer the
patch until it's done, I see no problem. Others may apply the patch as
needed for now.
> be more appropriate to have just automatically enabled this workaround for
> systems that are affected? If we keep it user-selectable then we at least
The workaround affects gcc's code generation -- there is no way to change
it at the run time.
> want a safety check somewhere in the startup code telling users to rebuild
> their code with the workaround enabled.
Of course, as I've written above.
> Having this workaround enabled by default would also ensure Linux
> distributions ship working code - you don't want users having to recompile
> their whole distribution ...
But the generated code is worse -- it interlocks on a multiplication
flushing the whole benefit of the separate multiply unit down the drain.
There is room for an improvement here, though.
As to compiling userland -- the workaround is the gcc's default for R4000
which is what is selected by "-mips3" among others. It should probably be
enabled by default for "-mips1" and "-mips2" configurations as well if no
explicit CPU selection options are passed.
Ultimately we'll want to have a separate setting for the R4400 in the
kernel as well, due to a smaller set of bugs.
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+ e-mail: firstname.lastname@example.org, PGP key available +