From: Francois Wellenreiter <Francois.Wellenreiter@Ext.Bull.Net>
To: linux-ia64@vger.kernel.org
Subject: Re: Abnormal behaviour towards "INIT" interrupt management
Date: Wed, 31 Mar 2004 06:37:01 +0000 [thread overview]
Message-ID: <406A670D.8040101@Ext.Bull.Net> (raw)
In-Reply-To: <40691B80.9070309@Ext.Bull.Net>
>>Then I push on the "dump" button that generates an INIT interruption to
>>all the processors. This signal is then caught by PAL, and SAL which
>>calls (with a reason [register GR11] equal to 2)
>>"ia64_monarch_init_handler" on the monarch processor and
>>"ia64_slave_init_handler" on the slave ones (to this point, I hope to be
>>right, isn't it ?).
>
>
> Yes. If I understand correctly, you observe that one processor
> calls ia64_monarch_init_handler(), and all the others call
> ia64_slave_init_handler(). So far, that is correct behavior.
Hum, in fact, that's the behaviour I was expecting to observe... reading
the kernel code.
>>What I've noticed using traces (and further an ITP tool) is that for
>>each processor the "ia64_monarch_init_handler" is ever called. :-(
>
>
> Are you saying that more than one processor calls
> ia64_monarch_init_handler()? If so, I think something
> is broken. But I haven't seen that behavior. Here is
> ia64_slave_init_handler():
>
> GLOBAL_ENTRY(ia64_slave_init_handler)
> 1: br.sptk 1b
> END(ia64_slave_init_handler)
>
Right, I was just surprised to see 4 times the trace "Entered OS INIT
handler" appearing on my console screen. Then, I ran a JTAG debugger
to set breakpoints in the kernel code and noticed that all CPUs called
the same function, e.g. "ia64_monarch_init_handler" (without using
any Rendez-Vous mechanism ?!).
> So I'd be surprised to see the slave processors do anything
> interesting.
>
> I do know that we are missing some useful behavior in this area --
> namely, we don't extract the min-state area for the slave processors,
> so we don't get backtraces for the currently-running tasks on them.
On that precise point, I thougt that PAL was recording register states
in a processor dedicated area called "min-state area" for each processor
receiving INIT signal (and in the present case all the processors catch
it). Can you confirm this ?
In fact, I want to be able pushing the "dump" button to get the
information for all the running processors (and not just one) and then
determine for example which one is "deadlocking".
next prev parent reply other threads:[~2004-03-31 6:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-30 7:02 Abnormal behaviour towards "INIT" interrupt management Francois Wellenreiter
2004-03-30 15:19 ` Bjorn Helgaas
2004-03-30 18:52 ` Luck, Tony
2004-03-31 6:37 ` Francois Wellenreiter [this message]
2004-03-31 6:43 ` Francois Wellenreiter
2004-03-31 19:44 ` Bjorn Helgaas
2004-04-01 3:23 ` Jim Garlick
2004-04-01 6:26 ` Francois Wellenreiter
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=406A670D.8040101@Ext.Bull.Net \
--to=francois.wellenreiter@ext.bull.net \
--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