All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Joshua Kinard <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org
Subject: Re: IP30: SMP, Almost there?
Date: Fri, 22 May 2015 18:38:27 +0200	[thread overview]
Message-ID: <20150522163826.GB6467@linux-mips.org> (raw)
In-Reply-To: <555D7469.7090806@gentoo.org>

On Thu, May 21, 2015 at 02:00:09AM -0400, Joshua Kinard wrote:

> Where I am lost is, though, why would I get an IBE on a 'beqz' instruction?
> It's a valid instruction from MIPS-I ('beqz' is just 'beq' w/ $0 as rt).  the
> R10K Manual states this:
> 
> """
> A Bus Error exception occurs when a processor block read, upgrade, or
> double/single/partial-word read request receives an external ERR completion
> response, or a processor double/single/partial-word read request receives an
> external ACK completion response where the associated external
> double/single/partial-word data response contains an uncorrectable error. This
> exception is not maskable.
> """
> 
> My guess is there's still something not kosher with icache flushing somewhere.
>  I can reboot this kernel multiple times and not always get the same IBE.  Most

Not or improperly flush the I-cache will result in stale instructions
getting executed.  An IBE error otoh is the result of a bus error being
signalled for the CPU's attempt to load instructions from memory.  With
the exception of a few special cases I-cache flushing doesn't happen
when eecuting kernel code, but only for userland and it's also somewhat
unlikely for improper I-cache flushing to result in an IBE error.

A huge problem tracking down the cause of a bus error is that they're
getting signalled by an external agent that is they are not generated by
the CPU itself and there may be a significant delay until the CPU
actually takes the exception.  In my experience the EPC is practically
always worthless in tracking down the cause of the bus error.  Details
depend on circumstances, as usual.

  Ralf

  parent reply	other threads:[~2015-05-22 16:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-18  5:39 IP30: SMP, Almost there? Joshua Kinard
2015-05-18 12:01 ` Joshua Kinard
2015-05-20  5:23   ` Joshua Kinard
2015-05-21  6:00     ` Joshua Kinard
2015-05-22 12:01       ` Maciej W. Rozycki
2015-05-22 17:11         ` Ralf Baechle
2015-05-23 22:52           ` Joshua Kinard
2015-05-24 14:25             ` Maciej W. Rozycki
2015-05-22 16:38       ` Ralf Baechle [this message]
2015-05-23 22:57         ` Joshua Kinard
2015-05-22 16:25   ` Ralf Baechle
2015-05-24  3:17 ` Joshua Kinard
2015-06-01  5:08   ` Joshua Kinard
2015-06-01  6:00     ` IP30: SMP, Almost there! Joshua Kinard
2015-06-01 19:32   ` IP30: SMP, Almost there? Ralf Baechle
2015-06-02  5:31     ` Joshua Kinard

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=20150522163826.GB6467@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=kumba@gentoo.org \
    --cc=linux-mips@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.