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

Re: Linux/MIPS for DECstations...

To: linux-mips@fnet.fr
Subject: Re: Linux/MIPS for DECstations...
From: Ralf Baechle <ralf@cobaltmicro.com>
Date: Tue, 30 Sep 1997 14:12:04 -0700 (PDT)
In-reply-to: <XFMail.970930212753.harald.koerfgen@netcologne.de> from "Harald Koerfgen" at Sep 30, 97 08:54:07 pm
Hi,

> I am still hacking Paul's 2.1.14.2.dec kernel. After messing around with 
> head.S 
> yesterday I restored to Paul's original head.S this evening and now I am 
> getting
> a different error message:
> 
> ..
> About to init memory
> mem_init called with start_mem: 8018a018, end_mem: 82fff000
> mem_init now has start_mem: 8018b000, end_mem: 82fff000
> Memory: 47568k/49148k available (524k kernel code, 864k data)
> About to init buffers
> memsize is: 2fff000
> about to vmalloc hash table
> vmalloc'd hash table, addr is: c0000000

This address is ok.

> about to clear hash table
> [swapper:0:00000822:1:8003aab8]do_page_fault() #2: sending SIGSEGV to swapper 
> fo
> r illegal writeaccess to
> 00000822 (epc == 8003aab8, ra == 80070e54)
> 
> which makes a *little* bit more sense to me. Strange, even the smallest 
> changes
> seem to produce very different effects. Uhmmm... isn't that characteristic for
> chaotical behaviour? ;-)

Ok, bug #1:


[...]
        lw      k1, THREAD_PGDIR(k1)
        sll     k0, k0, 2
        addu    k1, k1, k0
        mfc0    k0, CP0_CONTEXT
        lw      k1, (k1)
        srl     k0, k0, 1
        and     k0, k0, 0xffc
        addu    k1, k1, k0
        lw      k0, (k1)
[...]

Unlike the R4000 (64bit!) the R3000 context register refers to an array of
four byte entries.  So you must delete the srl instruction.

> I don't want to bother this list with kBytes of listings. If you are really
> interested in the version of head.S I am presently using, you can download
> it from http://ww.netcologne.de/~nc-koerfgha/head.S.

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 ...

  Ralf

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