linux-mips-fnet
[Top] [All Lists]

Re: Linux/MIPS for DECstations...

To: linux-mips@fnet.fr
Subject: Re: Linux/MIPS for DECstations...
From: Harald Koerfgen <harald.koerfgen@netcologne.de>
Date: Wed, 01 Oct 1997 19:53:34 +0200 (MEST)
In-reply-to: <199709302112.OAA04252@dull.cobaltmicro.com>
Sender: harry@franz.netcologne.de
Hi,

On 30-Sep-97 Ralf Baechle wrote:

>Your handler seems to die in the second level exception handler.
>However in buffer_init(), where the vmalloc'ed memory is being cleared,
>the pages are always readable/writeable and therefore that handler should
>never be reached.  Note that the way that handler in head.S is implemented
>the load in the handler should never cause a second fault.
>
>Nevertheless, for your case the superfluous srl instruction shouldn't make
>a difference.  Note that the R3000 exception mechanism is a bit different
>from the R4000, which means I'll have to read a bit ...

Me too...

Ok, all documentation about MIPS Processors are the "IDT R30xx Family Software
Reference Manual" from IDT and the "MIPS R4000 Microprocessor User's Manual" 
from SGI.

[hours later]

After carefully re-resing the IDT Manual ant glance at the SGI Manual, it is my 
understanding, that indeed there is a difference in the exception mechanism
between the R3000 and the R4000.

R4000:
*All* TLB misses cause a TLB refill exception. If a TLB miss happens in the
exception routine itself, a TLBL or TLBS exception is caused. This is handled
bye the general exception handler.

R3000:
*Only* references to KSEG0 (0x00000000- 0x7fffffff) may cause a TLB exception.
TLB misses with references to KSEG2 (0xc0000000 - 0xffffffff !!!) cause a TLBL 
or TLBS exception, which is handled by the general exception handler.

Just to make shure, that I understand this right: can anybody on the list
confirm this?
  
This could explain, why the kernel seems to die in the second level eception
handler. It's simply a reference to the freshly vmalloced hash table.

Paul wrote:

>...I should probably say that I think this code is of dubious
>parentage!  It would probably be best for you to look closely at the
>MMU code.  I was only just getting my head around the R3K MMU when I
>ran out of time to keep working on it, so I'd suggest you might even
>want to throw it away and write it again!

That would be the best. Ok, if nobody else wants to do it, I'll start rewriting
the R3000 TLB stuff.

-- 
cheers
Harald

<Prev in Thread] Current Thread [Next in Thread>