linux-mips
[Top] [All Lists]

Re: Troubles with TLB refills

To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: Troubles with TLB refills
From: Liam Davies <ldavies@agile.tv>
Date: Tue, 06 Mar 2001 13:10:27 +1000
Cc: linux-mips@oss.sgi.com
Organization: Agile TV
References: <3AA30A91.B5842678@agile.tv> <20010305114926.A26862@bacchus.dhis.org>
Reply-to: ldavies@oz.agile.tv
Sender: owner-linux-mips@oss.sgi.com
Ralf Baechle wrote:

> This exception handler has been modified since the version tested in the
> Cobalt Qube and I'm not sure if the bug workaround actually got tested
> since then.
>

It seems to work now.

> handle_page_fault got called and printed something; therefore the
> exception handler cannot possibly have been trashed.  do_page_fault gets
> called by via the generic exception handler.  The TLB vectors there are only
> taken if there is a TLB entry matching the address in the TLB.  Therefore
> your theory about no tlb refill exception cannot be right.

And this is the way I understood the workings as well.

> The TLB
> dump only displays entries where at least on of the entry0 / entry1
> entries is valid, therefore you get an empty dump; maybe that made you
> believe you didn't get a TLB reload exception.

No, this is what I expected in the TLB since this was the first kuseg access.

Not long after posting this message I found the problem.  The exception handler

had been trashed, *before* it was copied to 0x80000000. I'm not sure what
trashed it yet, that is a job for later. What made this whole thing more
puzzling
is the actual stuff that was in 0x80000000 was absolute trash, it made no sense

in terms of instruction encodings. I would have thought the cpu would have
crapped out when it hit bad instructions. So it would seem the
exceptions were occurring but the code that it was executing wasn't even code.
Hence my assumption that we never got a TLB refill., even though the fault
handler was being called.

Liam




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