On Tue, 29 May 2012, Ralf Baechle wrote:
> > It was not a bug, or at least not an active one. The new encoding was
> > only added with revision 3 of the architecture or thereabouts, so not so
> > long ago. It used to be reserved previously, so we just handled it
> > arbitrarily (though perhaps we should have panicked instead on
> > encountering it indeed).
>
> The patch at least was applicable to all 2.4 and 2.6 branches ...
That you could have backported the change to old code doesn't mean the
code was buggy at the time it was written. It only became buggy as the
environment changed.
I have now double-checked my resources and according to the revision
history of the architecture spec, the new encoding was only added with
revision 3.00 of the spec: "Added encoding (0x7) for 32 sets for one cache
way." that was dated March 2010 (my copy of revision 2.80 certainly does
not list it and 3.05 does; I don't have the exact 3.00 revision
unfortunately). Up until then 64 was the smallest number of ways
supported (and 7 was listed as a reserved encoding, just as when the code
you've just patched was written).
Linux 2.6.33 was released in February 2010 and 2.6.34 in May. So
anything before 2.6.34 was never buggy, and certainly none of 2.4 kernels.
You now have the answer to your concern as to how long we survived with
this bug too: 2 years and 2 months. Not too bad. ;)
I still wonder why the 4Kc is mentioned in this context, this is a MIPS32
revision 1 architecture chip, so revision 3 cannot apply to it anyway,
hmm...
Maciej
|