Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: David VomLehn <dvomlehn@cisco.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: joe seb <joe.seb8@gmail.com>, linux-mips@linux-mips.org
Subject: Re: Linux port failing on MIPS32 24Kc
Date: Wed, 8 Jul 2009 11:25:00 -0700	[thread overview]
Message-ID: <20090708182500.GA31285@cuplxvomd02.corp.sa.net> (raw)
In-Reply-To: <20090708103756.GB22308@linux-mips.org>

On Wed, Jul 08, 2009 at 11:37:56AM +0100, Ralf Baechle wrote:
> On Wed, Jul 08, 2009 at 01:37:42PM +0530, joe seb wrote:
> 
> > We are trying to port linux 2.6.29.4 version of the kernel from
> > linux-mips.org site to our MIPS 24K based platform and we see issues when we
> > use the cache in write-back mode. Cache with write-through configuration
> > works fine.
...
> > CPU 0 Unable to handle kernel paging request at virtual address cccccccc,
> > epc ==
> >  cccccccc, ra == cccccccc
...
> > We get crashes at different places and the above crash is one of them.
> > Do you think this failure is due to the wrong cache configuration or related
> > to the d-cache aliasing problem?

In a narrow sense, when you get a page fault at an address that equals the
value of the EPC register and the ra register is the same value, you have
probably smashed your stack. Specifically, you smashed the location where
the ra value was stored on function entry. When you restored it to ra and
did a jr ra, you put the value in the pc register.

One possible cause is a stack overflow. This is unlikely, but I've seen
drivers put big enough buffers on the stack that it intruded into the
thread_info area. This causes all sorts of badness to happen.

> (Why do people use non-zero starting addresses for memory?  Handling of
> cache error exceptions is hard enough as it is but with no memory in the
> low 32k the design idea of the cache architecture that stores relative to
> $zero can be used goes down the drain and (not considering platform-specific
> solutions here) only be handled by burning the scarce resource of a TLB
> entry for an extremly rare event ...)

(Because hardware people are, uh, insufficiently acquainted with the MIPS
architecture and don't know what the conventions are. Or why they are that
way. Then, you're stuck with that architecture forever. Sigh.)

>   Ralf

David VomLehn

  parent reply	other threads:[~2009-07-08 18:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-08  8:07 Linux port failing on MIPS32 24Kc joe seb
2009-07-08 10:37 ` Ralf Baechle
2009-07-08 12:47   ` joe seb
2009-07-08 18:29     ` David VomLehn
2009-07-09 11:05       ` joe seb
2009-07-12 10:39         ` Eugene Surovegin
2009-07-08 18:25   ` David VomLehn [this message]
2009-07-08 19:11     ` Maciej W. Rozycki
2009-07-13 14:47   ` joe seb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090708182500.GA31285@cuplxvomd02.corp.sa.net \
    --to=dvomlehn@cisco.com \
    --cc=joe.seb8@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox