public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Bryan Sutula <Bryan.Sutula@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Handling nested MCA/INIT
Date: Mon, 17 Oct 2005 16:01:21 +0000	[thread overview]
Message-ID: <1129564881.19773.18.camel@xw.sutula> (raw)
In-Reply-To: <6443.1129561424@ocs3.ocs.com.au>

On Tue, 2005-10-18 at 01:03 +1000, Keith Owens wrote:

> The current MCA/INIT handlers run with psr.mc = 1, so nested events
> cannot be delivered.  This makes it impossible to use the nmi button to
> find out why the MCA/INIT handler is hung.  I am thinking of changing
> mca_asm.S to set psr.mc to 0 to allow nested events.  The handlers
> would detect a nested event, gather minimal diagnostics then reboot.
> Then we may be able to diagnose hung MCA/INIT handlers, right now we
> get no data for this case, which is extremely frustrating.

Your suggestion seems better than a hang.  In a production environment,
it's pretty important to be able to reset the machine reliably.

> The only downside that I can see is if the handler is accessing memory
> with a hard double bit error, we could get nested MCA events.  Since
> the only thing we can do if the MCA handler gets an MCA is to reboot,
> the nested event is not really a problem and allowing nested MCA may
> still give us better diagnostics.

Another issue I see is the case where a second MCA occurs fairly soon
after the first.  With your proposed change, we may lose some of the
information on the first.  (E.g., the handler wasn't hung but just
"doin' it's thing".)  Would there be a way to detect the difference
without complicating the code to the point where it would be unreliable?

-- 
Bryan Sutula <Bryan.Sutula@hp.com>


      reply	other threads:[~2005-10-17 16:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-17 15:03 Handling nested MCA/INIT Keith Owens
2005-10-17 16:01 ` Bryan Sutula [this message]

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=1129564881.19773.18.camel@xw.sutula \
    --to=bryan.sutula@hp.com \
    --cc=linux-ia64@vger.kernel.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