> On Wed, Jul 10, 2002 at 04:49:00PM -0700, H. J. Lu wrote: > > > > See the crash scene. Anybody knows the cause? It is strange to see the > > > reserved exception. > > > > > > > The 2.4 kernel checked out around Jul 4 09:28 PDT works fine on Malta. > > Jun's patch certainly is correct for some MIPS32 CPUs; others may get > away without this one. Previous experience with pipeline hazards on MIPS > processors has shown that at times hazards may change even between minor > revisions of a CPU; documentation isn't always trustworthy about such > minor details of the pipeline. Excuse me, but I've seen this statement used by others in the past as an excuse for doing something silly or not doing something reasonable, and it generally hasn't washed. In what specific cases have the CP0 pipeline hazards changed between minor revisions of any production MIPS CPU? The *documentation* may have been corrected, but these hazards are fairly fundamental artifacts of the pipeline microarchitecture of a given processor. The CP0 hazard between a write of EntryHi and a subsequent TLBWI instruction is flagged in the MIPS32 spec and noted as being "typically" 2 cycles. I'm not going to spend the time going through my full set of users manuals, but a representative sampling shows this hazard as being specified for every R4xxx and R5xxx CPU I checked. The fact that a given CPU *may* get away with it is no excuse for not protecting common code. I note that Ralf has, in fact, applied the fix to the OSS CVS repository. I also note that "BARRIER" is still defined to be a string of 6 nops. I would argue (again) that those really, really ought to be ssnops, and that if they *were* ssnops, one could probably have fewer of them. Regards, Kevin K.