All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cliff Larsen <clarsen@egenera.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] make INIT# handler call panic
Date: Fri, 05 Nov 2004 22:57:29 +0000	[thread overview]
Message-ID: <1099695448.913.242.camel@clarsen> (raw)
In-Reply-To: <1099662943.913.180.camel@clarsen>

On Fri, 2004-11-05 at 17:04, Bjorn Helgaas wrote:
> My $0.02 is that it *is* annoying that we just hang after printing
> the INIT register state and backtraces.  However, I wonder if we
> could just leverage the existing panic_timeout (set by "panic=")
> so we don't need a new parameter.

I'm fine with that.

> I don't have an opinion about whether calling panic from
> init_handler_platform() is the right thing to do or not.
> Certainly it is a good place for some sort of hook for a
> debugger and/or crashdump.

My major motivation was to get to a crashdump hook and get 
to restart, and panic does both, so I chose it.

> My personal preference would be something like this:
>    1) dump register state (for all CPUs, not just the INIT monarch)
>       on the console
>    2) print backtraces (maybe just for currently-running tasks;
>       currently we do the task on the INIT monarch plus all other
>       non-running tasks, which is definitely non-optimal)
>    3) optional debugger/crashdump hook
>    4) call panic (maybe)
>    5) optional timeout, then reboot (if not calling panic)
> 
> Part 5 would be trivial and probably not *too* controversial.
> Part 1 is harder but extremely useful, and I think someone (Zoltan?)
> posted a start.  Part 2 should be simple given part 1.

I'll see what I can do about most of these. Part 1 would be
difficult since the hardware/firmware we've currently got 
available makes both processors the monarch on INIT.

Thanks for your feedback,
   Cliff


  parent reply	other threads:[~2004-11-05 22:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-05 13:55 [PATCH] make INIT# handler call panic Cliff Larsen
2004-11-05 16:26 ` Bjorn Helgaas
2004-11-05 21:04 ` Cliff Larsen
2004-11-05 22:04 ` Bjorn Helgaas
2004-11-05 22:57 ` Cliff Larsen [this message]
2004-11-05 23:04 ` Russ Anderson
2004-11-08 12:14 ` Takao Indoh
2004-11-10 15:53 ` Philip R Auld
2004-11-11  0:55 ` Takao Indoh
2004-11-11  1:14 ` Luck, Tony
2004-11-11 17:12 ` Cliff Larsen
2004-11-11 17:18 ` Cliff Larsen
2004-11-11 17:33 ` Luck, Tony

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=1099695448.913.242.camel@clarsen \
    --to=clarsen@egenera.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 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.