> I am still hacking Paul's 18.104.22.168.dec kernel. After messing around with
> yesterday I restored to Paul's original head.S this evening and now I am
> 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
> r illegal writeaccess to
> 00000822 (epc == 8003aab8, ra == 80070e54)
> which makes a *little* bit more sense to me. Strange, even the smallest
> 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 ...