Subject: Re: k0/k1 register while mulhi/mullo manipulation
To: None <port-mips@netbsd.org, port-pmax@netbsd.org>
From: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
List: port-mips
Date: 02/23/2000 21:48:08
>> My vague memory whispers me 'k0/k1 contents might be trashed under certain
>> circumstances, e.g., after calling mt*/mf* for mulhi/mullo'.
>> "(Even) when CPU is running kernel mode and no TLB miss is expected,"
>    ...
> MIPS interrupt handling hardware is extremely minimal
> and that is what requires at least one general register to be trashed by
> interrupt handlers no matter what (they can't return without it).

Probably my memory is confused by other kind of misplaced "lw k0, ..."
incident.  You are right, I know MIPS has far less interlocked design.

Now, I could build another, more likely, reasoning why recent
NetBSD/pmax kernels (1.4T) lock up sporadorically; an unexpected
interrupt during critical section.  Let see following locore_mips1.S
change;

+       lw      k0, TF_BASE+TF_REG_EPC(sp)
        mtc0    a0, MIPS_COP_0_STATUS
        mtlo    t0
        mthi    t1
-       lw      k0, TF_BASE+TF_REG_EPC(sp)
        ...
        j       k0
	rfe
	
The 'mtc0 a0, ...' insn has the effect to make sure no more interrupt.
But if the new code sequence got an interrupt after 'lw k0, ...'
before 'mtc0 a0, ...', k0 would be trashed by the interrupt handler
(not by mtlo/mthi insns) and glok in a hidious way.  How is this
senario?

Tohru Nishimura