Re: Abnormal behaviour towards "INIT" interrupt management

From: Bjorn Helgaas <bjorn.helgaas_at_hp.com>
Date: 2004-03-31 01:19:27
On Tuesday 30 March 2004 12:02 am, Francois Wellenreiter wrote:
> 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.

> 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)

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.

Bjorn


-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Mar 30 10:27:15 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:25 EST