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
|