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

Re: vmalloc help??

To: linux-mips@guadalquivir.fnet.fr
Subject: Re: vmalloc help??
From: Systemkennung Linux <linux@informatik.uni-koblenz.de>
Date: Tue, 13 May 1997 21:11:14 +0200 (MET DST)
In-reply-to: <199705101358.NAA19648@suede.sw.oz.au> from "Paul Antoine" at May 10, 97 11:58:45 pm
Hi,

> I've discovered the latest point at which the DECStation kernel is failing:
> namely in accessing KSEG2 after having vmalloc'd a hash table for the buffers.
> 
> Can anyone with good knowledge of this help?  It seems that vmalloc is
> allocating an address of 0xc0000000 for the table, and that any access of 
> this hangs...

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.

That first vmalloc on a Linux/MIPS system will return a pointer to
the address 0xc0000000 aka KSEG2.  The chunks returned by vmalloc are
separated by at least one unmapped 4kb page.  This helps to catch
out off bounds accesses.

With 99.9% probability your problem is in the TLB exception handler.

Try some code like the following:

        x = vmalloc(PAGE_SIZE);
        *(unsigned int *)x = 42;

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?

.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.  The good
news is the current stuff makes a *lot* less of headache, specially
on CPUs with virtual indexed caches like the R4k.

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

  Ralf

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