Hi Maciej, > > Anyway, as noted above that shouldn't cause a problem with user software > > and I think that any corruption you can see comes from elsewhere. You'll > > have to paper this $ra non-sign-extension issue over somehow to proceed > > though. > > During early kernel initialisation at least one other register (besides > $ra) appears to fail the sign-extension test, and the error cannot be > ignored. I will now try figure this out. Trap 12 is causing kernel inconvenience resulting in "kernel bug" crashes when triggering sign-extension failures for the remaining registers. As a less intrusive measure I've collected some statistics: Failed registers are marked by bit position in 0x8000FF74, hence registers $v0, $a0-$a2, $t0-$t7 and $ra fail the sign-extension test. Problems are present during kernel initialisation, so either 1) the R5900 is not really 32-bit compatible, 2) the compiler is somehow generating 64-bit code, 3) assembler directives in the R5900 patch produce 64-bit code, or 4) the sign-extension tests are wrong (or a combination of the above). In principle, I suppose one could carefully write assembly code to save all registers and stack traces in a reserved memory area for later examination, avoiding "kernel bug" crashes when immediately triggering trap 12 in a sensitive kernel context. What are your thoughts on how to proceed? Fredrik
