Subject: LEXRA MIPS

From: Tim Wu <[email-masked]>
Date: Fri, 12 Apr 2002 15:29:12 +0800

Hi, everybody:
I'm working on porting Linux to a MIPS based processor whose IP is from 
Lexra's LX4189 processor.

I started my work from the linux MIPS port of oss.sgi.com.  Right now 
the kernel can boot and run some user applications well.

But I met a problem that once a process raises any kind of signal, 
kernel will send a SIGILL signal to the process which let the process stop.

I traced the kernel source and found SIGILL is sent by the exception 
handler, do_ri().

The problem is very weird because when I change to another crosscompiler 
or insert some asserting code to functions in signal.c.  The kernel 
become unbootable.  I hope someone can give me directions to solve this 
bug or tell me who already done Linux on Lexra?

kernel version:2.4.17.
toolchain: GCC 3.1 from ftp.cotw.com.
use new IRQ and new timer interface.

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Fri, 12 Apr 2002 07:41:44 -0400

----- Original Message -----
From: "Tim Wu" <[email-masked]>
To: "linux-mips" <[email-masked]>
Sent: Friday, April 12, 2002 3:29 AM
Subject: LEXRA MIPS

> I traced the kernel source and found SIGILL is sent by the exception

Can you tell what/where the reserved (illegal) instruction is that causes
the trap?

Regards,
Brad

---

From: Tim Wu <[email-masked]>
Date: Sat, 13 Apr 2002 16:02:49 +0800

I insert a show_registers() into the begining of do_ri().
It seems that CPU runs into data section.

$0 : 00000000 1000fc00 00000014 00000000 00000001 00000000 00000000 00000000
$8 : 0000fc00 7fff7a78 00000000 00000002 00000000 00000000 00000000 00000002
$16: 00000004 7fff7e10 7fff7e18 00000000 100604b0 00000600 7fff7e28 00000010
$24: 810d6080 00000000                   1005e870 7fff7a58 7fff7db0 7fff7a68
Hi : 00000000
Lo : 00000000
epc  : 7fff7aa8    Not tainted
Status: 0000fc0c
Cause : 10000028
Process ping (pid: 24, stackpage=81ff2000)
Stack: 386d4381 31323100 00000000 00000000 24021000 00000000 00000000 0000fc0c
        2ab39a1c 00000000 00000000 00000000 2ab9f550 00000000 00000200 00000000
        00000000 00000000 00000003 00000000 7fff7d08 00000000 000000c0 00000000
        00000000 00000000 0000fc00 00000000 81ff0210 00000000 00000000 00000000
        00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        00000002 ...
Call Trace:
Code: 00000000  00000003  00000000 <7fff7d08> 00000000  000000c0  00000000 
00000000  00000000

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Sat, 13 Apr 2002 10:44:47 -0400

You say this only happens when a process raises a signal.

Maybe the signal trampoline is getting messed up.

Do you see the same behaviour with and without a signal handler installed
for the raised signal?

Regards,
Brad