[Top] [All Lists]

Re: vmalloc help (aka R3000 TLB help)

Subject: Re: vmalloc help (aka R3000 TLB help)
From: (Paul Antoine)
Date: Wed, 14 May 1997 11:41:48 +1000 (EST)
In-reply-to: <> from "Systemkennung Linux" at May 13, 97 09:11:14 pm
Organization: Softway Pty Ltd
Ralf wrote:

> Well, buffer_init() where vmalloc() is called for the first time is
> a first check of your R3000 specific mm stuff, especially the TLB
> exception handler.
> With 99.9% probability your problem is in the TLB exception handler.

Yep, I've managed to narrow it down to that...

> Try some code like the following:
>       x = vmalloc(PAGE_SIZE);
>       *(unsigned int *)x = 42;

This is exactly the sort of code in vmalloc that is failing.

> and add code to the TLB exception handler (at KSEG0) to print out the
> content of the TLB's entries.


> What non-wired TLB entries do you have?  Are they correct?

Ummm... there are no wired entries.  I've no idea what non-wired
entries I have, nor whether they are correct.

> .37 does no longer use the old scheme were a processes' page tables
> were also mapped at the address TLBMAP (0xe4000000), so you will
> have to rewrite the TLB exception handlers for the R3000.

I see...

> The good news is the current stuff makes a *lot* less of headache,
> specially on CPUs with virtual indexed caches like the R4k. the code for the R3K will be very different I assume.

> Debugging these handlers is nasty and can easily lead you to
> undocumented MIPS ...

It is an almighty pain, but in other ways quite satisfying when it
works... :-)

Paul M. Antoine,                                        Net:
Softway Pty Ltd                                         WWW:
PO Box 305, Strawberry Hills, NSW 2012, Australia       Tel: +61 2 9698 2322
Level 2, 79 Myrtle St, Chippendale, NSW 2008, Australia Fax: +61 2 9699 9174

"It is the lack of acceptance of diversity which threatens to 
 destroy society, NOT the free expression of it." - Me.

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