Re: MIPS Alchemy machine don't boot

KIYOHARA Takashi wrote:

> Hi! all
> 
> From: KIYOHARA Takashi <[email protected]>
> Date: Thu, 07 Jan 2010 14:42:22 +0900 (JST)
> 
> > My MIPS Alchemy machine(OMSAL400) is reported on the error the other day
> > and doesn't boot.
> 
> > pid 0(system): trap: reserved instruction in kernel mode
> > status=0x2, cause=0x80808028, epc=0x8020b8a4, vaddr=0xc7df50df tf=0x804f8de8 ksp
> > =0x804f8e48 ra=0x802e2e58
> > Stopped in pid 0.1 (system) at  0x8020b8a4:     bne     t0,zero,0x8020b8c0
> >                 bdslot: daddu   t2,s7,zero
> 
> > I look the current kernel and the old kernel.  The instruction is obviously
> > different.
> 
> Also look this.
> 
> http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201001050000Z/evbmips/binary/sets/kern-OMSAL400.tgz
> 
> 80212960 <mutex_enter>:
> 80212960:       c0880000        lwc0    $8,0(a0)
> 80212964:       15000006        bnez    t0,80212980 <mutex_enter+0x20>
> 80212968:       02e0502d        0x2e0502d
> 8021296c:       e08a0000        swc0    $10,0(a0)
> 80212970:       1140fffc        beqz    t2,80212964 <mutex_enter+0x4>
> 80212974:       c0880000        lwc0    $8,0(a0)
> 
> 
> I was convinced that the relation was not in nbmake-cobalt.
> Does anyone understand the cause and the means for solving the problems?

Digging deeper:

We have an instruction 0x2e0502d.  In binary, that's

	000000 10111 00000 01010 00000 101 101

The first 6 are 0's, according to the MIPS64 instruction set doco, makes
is a "special" instruction (table A-2).  The last 6 bits are 101 101,
which in the special table makes it DADDU (table A-3).  DADDU is an
R-Type instruction, so the source regs are the first two 6 bit groups
(23 and 0) and the target reg is the next 5 bits (10).  We ignore the
last five bit grouping for this instruction.  This gives:

	DADDU	$23,$zero,$10

$23 is MIPS_CURLWP and $10 is t2.  This matches the asm code in
lock_stubs.S here:

	move	t2, MIPS_CURLWP

Adding a given register to "zero" is used for move when in a 64-bit ABI.

This is all sounding like some 64-bit code merge issue.  I wonder if any
32-bit evbmips machines were tested during or after that merge?

Cheers,
Simon.