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
