INIT handler modification

INIT handler modification

[Francois Wellenreiter]

				Dear all,


	first of all, my best wishes for this new year.
Second, I just wanted to start a discussion about INIT handler 
considerations.
Here is the main point, the present code of INIT handler for slave CPUs 
is reduced
to (file arch/ia64/kernel/mca_asm.S) :
______________________________

GLOBAL_ENTRY(ia64_slave_init_handler)
1:      br.sptk 1b
END(ia64_slave_init_handler)
______________________________

I think that when the kernel is deadlocked on another CPU than the 
monarch one,
the traces may be a bit short when I push on the "DUMP" button to have a 
complete
diagnosis of my system.

Thus, I propose you to change the following code (file 
arch/ia64/kernel/mca.c)
______________________________

void __init
ia64_mca_init(void)
{
         ia64_fptr_t *mon_init_ptr = (ia64_fptr_t 
*)ia64_monarch_init_handler;
         ia64_fptr_t *slave_init_ptr = (ia64_fptr_t 
*)ia64_slave_init_handler;
.....
______________________________

into

______________________________

void __init
ia64_mca_init(void)
{
         ia64_fptr_t *mon_init_ptr = (ia64_fptr_t 
*)ia64_monarch_init_handler;
         ia64_fptr_t *slave_init_ptr = (ia64_fptr_t 
*)ia64_monarch_init_handler;
.....
______________________________

What do you think about it ? Do you fear it may induce an unwanted 
behavior towards MCA handling ?

Best regards,

					Francois WELLENREITER

Re: INIT handler modification

[Bjorn Helgaas]

On Fri, 2005-01-07 at 15:13 +0100, Francois Wellenreiter wrote:
> Here is the main point, the present code of INIT handler for slave CPUs 
> is reduced
> to (file arch/ia64/kernel/mca_asm.S) :
> ______________________________
> 
> GLOBAL_ENTRY(ia64_slave_init_handler)
> 1:      br.sptk 1b
> END(ia64_slave_init_handler)
> ______________________________
> 
> I think that when the kernel is deadlocked on another CPU than the 
> monarch one,
> the traces may be a bit short when I push on the "DUMP" button to have a 
> complete
> diagnosis of my system.

You're right, this is a serious problem that needs to be fixed.
Unfortunately, it's a little more complicated than the change
you propose, because we need per-CPU areas (or locking) for
saving the min-state areas from firmware.  I think the recent
"per cpu MCA/INIT" changes are heading in this direction, so
please take a look at those, try them out, and improve them!

RE: INIT handler modification

[Luck, Tony]

>You're right, this is a serious problem that needs to be fixed.
>Unfortunately, it's a little more complicated than the change
>you propose, because we need per-CPU areas (or locking) for
>saving the min-state areas from firmware.  I think the recent
>"per cpu MCA/INIT" changes are heading in this direction, so
>please take a look at those, try them out, and improve them!

There should be enough parts of Russ Anderson's changes in the
http://linux-ia64.bkbits.net/linux-ia64-test-2.6.11 tree to give
this a try.  It should also show up in the next -mm patch (it
missed 2.6.10-mm2).

You'd need to add some serialization in ia64_init_handler() and/or
init_handler_platform() to make sure that all the cpus didn't stomp
all over each other printing their registers, and you'll only want
one of them to walk the tasklist providing backtraces.

-Tony

Re: INIT handler modification

[Keith Owens]

On Fri, 07 Jan 2005 15:13:31 +0100, 
Francois Wellenreiter <Francois.Wellenreiter@Ext.Bull.Net> wrote:
>Here is the main point, the present code of INIT handler for slave CPUs 
>is reduced
>to (file arch/ia64/kernel/mca_asm.S) :
>______________________________
>
>GLOBAL_ENTRY(ia64_slave_init_handler)
>1:      br.sptk 1b
>END(ia64_slave_init_handler)
>______________________________

The limitations on slave INIT and MCA handlers are mainly due to the
lack of kernel stacks to handle these events.  Russ Anderson (SGI) is
working on patches that add per cpu stacks for MCA and INIT.  Once
those patches are in the base kernel, we will be changing the INIT and
MCA slave handlers to use the multiple stacks.  That will give us real
processing for the slave events.

Re: INIT handler modification

[Russ Anderson]

Keith Owens wrote:
> Francois Wellenreiter <Francois.Wellenreiter@Ext.Bull.Net> wrote:
> 
> The limitations on slave INIT and MCA handlers are mainly due to the
> lack of kernel stacks to handle these events.  Russ Anderson (SGI) is
> working on patches that add per cpu stacks for MCA and INIT.  Once
> those patches are in the base kernel, we will be changing the INIT and
> MCA slave handlers to use the multiple stacks.  That will give us real
> processing for the slave events.

Tony has put the patches in his test-2.6.11 tree.  Those patches should
have enough support to allow the INIT and MCA slave handlers to use
the multiple stacks.  

Thanks,
-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com