[PATCH] i386 kexec: Allow the kexec on panic support to compile on voyager.

[PATCH] i386 kexec: Allow the kexec on panic support to compile on voyager.

[Eric W. Biederman]

This patch removes the foolish assumption that SMP implied local
apics.  That assumption is not-true on the Voyager subarch.  This
makes that dependency explicit, and allows the code to build.

What gets disabled is just an optimization to get better crash
dumps so the support should work if there is a kernel that will
initialization on the voyager subarch under those harsh conditions.

Hopefully we can figure out how to initialize apics in init_IRQ
and remove the need to disable io_apics and this dependency.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/i386/kernel/crash.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/i386/kernel/crash.c b/arch/i386/kernel/crash.c
index f10da80..67d297d 100644
--- a/arch/i386/kernel/crash.c
+++ b/arch/i386/kernel/crash.c
@@ -92,7 +92,7 @@ static void crash_save_self(struct pt_re
 	crash_save_this_cpu(regs, cpu);
 }
 
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_X86_LOCAL_APIC)
 static atomic_t waiting_for_crash_ipi;
 
 static int crash_nmi_callback(struct notifier_block *self,
-- 
1.4.1.gac83a

Re: [PATCH] i386 kexec: Allow the kexec on panic support to compile on voyager.

[Horms]

On Mon, 10 Jul 2006 16:37:49 -0600, Eric W. Biederman wrote:
> 
> This patch removes the foolish assumption that SMP implied local
> apics.  That assumption is not-true on the Voyager subarch.  This
> makes that dependency explicit, and allows the code to build.

Doesn't only a small portion of the code in question rely
on CONFIG_X86_LOCAL_APIC? Is just a workaround until proper
voager support materialises?

> What gets disabled is just an optimization to get better crash
> dumps so the support should work if there is a kernel that will
> initialization on the voyager subarch under those harsh conditions.

By that do you mean, a crash kernel that is able to boot even
though the non-crashing CPUs have not been shutdown?

> Hopefully we can figure out how to initialize apics in init_IRQ
> and remove the need to disable io_apics and this dependency.

That does sound nice. Do you have any ideas on how that could be 
made to happen?

> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> ---
> arch/i386/kernel/crash.c |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/i386/kernel/crash.c b/arch/i386/kernel/crash.c
> index f10da80..67d297d 100644
> --- a/arch/i386/kernel/crash.c
> +++ b/arch/i386/kernel/crash.c
> @@ -92,7 +92,7 @@ static void crash_save_self(struct pt_re
>        crash_save_this_cpu(regs, cpu);
> }
> 
> -#ifdef CONFIG_SMP
> +#if defined(CONFIG_SMP) && defined(CONFIG_X86_LOCAL_APIC)
> static atomic_t waiting_for_crash_ipi;
> 
> static int crash_nmi_callback(struct notifier_block *self,



-- 
Horms                                           
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Re: [PATCH] i386 kexec: Allow the kexec on panic support to compile on voyager.

[Eric W. Biederman]

Horms <horms@verge.net.au> writes:

> On Mon, 10 Jul 2006 16:37:49 -0600, Eric W. Biederman wrote:
>> 
>> This patch removes the foolish assumption that SMP implied local
>> apics.  That assumption is not-true on the Voyager subarch.  This
>> makes that dependency explicit, and allows the code to build.
>
> Doesn't only a small portion of the code in question rely
> on CONFIG_X86_LOCAL_APIC? Is just a workaround until proper
> voager support materialises?

Essentially, but it is correct for the code to stay this way.

>> What gets disabled is just an optimization to get better crash
>> dumps so the support should work if there is a kernel that will
>> initialization on the voyager subarch under those harsh conditions.
>
> By that do you mean, a crash kernel that is able to boot even
> though the non-crashing CPUs have not been shutdown?

I simply mean a crash kernel that is able to boot.

>> Hopefully we can figure out how to initialize apics in init_IRQ
>> and remove the need to disable io_apics and this dependency.
>
> That does sound nice. Do you have any ideas on how that could be 
> made to happen?

My patch for that got reverted because it wouldn't boot on Linus's
SMP laptop.  It appeared to be some weird ACPI problem.  I didn't
receive any bug reports otherwise.

So I suspect the steps are:
1) Unify SMP and non-SMP apic initialization so it is the exact same
   code.
2) Move the unified code up in the boot sequence into init_IRQs.

It is something that needs to be done very delicately.

Eric

Re: [PATCH] i386 kexec: Allow the kexec on panic support to compile on voyager.

[Horms]

On Tue, Jul 11, 2006 at 02:07:24PM -0600, Eric W. Biederman wrote:
> Horms <horms@verge.net.au> writes:
> 
> > On Mon, 10 Jul 2006 16:37:49 -0600, Eric W. Biederman wrote:
> >> 
> >> This patch removes the foolish assumption that SMP implied local
> >> apics.  That assumption is not-true on the Voyager subarch.  This
> >> makes that dependency explicit, and allows the code to build.
> >
> > Doesn't only a small portion of the code in question rely
> > on CONFIG_X86_LOCAL_APIC? Is just a workaround until proper
> > voager support materialises?
> 
> Essentially, but it is correct for the code to stay this way.

Is it neccessary for local apic to be present for all the code in the 
ifdef to work? It seems to me that the register saving code
could be made to work without it.

> >> What gets disabled is just an optimization to get better crash
> >> dumps so the support should work if there is a kernel that will
> >> initialization on the voyager subarch under those harsh conditions.
> >
> > By that do you mean, a crash kernel that is able to boot even
> > though the non-crashing CPUs have not been shutdown?
> 
> I simply mean a crash kernel that is able to boot.

I was hoping for some more specific information than that.

> >> Hopefully we can figure out how to initialize apics in init_IRQ
> >> and remove the need to disable io_apics and this dependency.
> >
> > That does sound nice. Do you have any ideas on how that could be 
> > made to happen?
> 
> My patch for that got reverted because it wouldn't boot on Linus's
> SMP laptop.  It appeared to be some weird ACPI problem.  I didn't
> receive any bug reports otherwise.

Do you have a link to the patch, or a copy of it floating around?

ACPI is the root of many evils, particularly as its bahaviour seems
to effect many different systems, and it behaves differently on
different machines. Perhaps the code could be cleaned up a little
and incoporated into -mm. In my experience the best way to solve ACPI
problems is to expose the code to as much hardware as possible.

> So I suspect the steps are:
> 1) Unify SMP and non-SMP apic initialization so it is the exact same
>    code.
> 2) Move the unified code up in the boot sequence into init_IRQs.
> 
> It is something that needs to be done very delicately.

Yes undersandably so. Sounds quite tedious :(

-- 
Horms                                           
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Re: [PATCH] i386 kexec: Allow the kexec on panic support to compile on voyager.

[Eric W. Biederman]

Horms <horms@verge.net.au> writes:

> On Tue, Jul 11, 2006 at 02:07:24PM -0600, Eric W. Biederman wrote:
>> Horms <horms@verge.net.au> writes:
>> 
>> > On Mon, 10 Jul 2006 16:37:49 -0600, Eric W. Biederman wrote:
>> >> 
>> >> This patch removes the foolish assumption that SMP implied local
>> >> apics.  That assumption is not-true on the Voyager subarch.  This
>> >> makes that dependency explicit, and allows the code to build.
>> >
>> > Doesn't only a small portion of the code in question rely
>> > on CONFIG_X86_LOCAL_APIC? Is just a workaround until proper
>> > voager support materialises?
>> 
>> Essentially, but it is correct for the code to stay this way.
>
> Is it neccessary for local apic to be present for all the code in the 
> ifdef to work? It seems to me that the register saving code
> could be made to work without it.

I don't know.  Is sending an NMI to all of the auxiliary processors
on the voyager subarch a sane thing todo?  Can we do that without a local
apic?

The only thing that really needs that tight of a guard to compile
is the disable apic code.

Basically explicitly depending on a local apic makes our true
assumptions and test cases visible in that code.

>> >> What gets disabled is just an optimization to get better crash
>> >> dumps so the support should work if there is a kernel that will
>> >> initialization on the voyager subarch under those harsh conditions.
>> >
>> > By that do you mean, a crash kernel that is able to boot even
>> > though the non-crashing CPUs have not been shutdown?
>> 
>> I simply mean a crash kernel that is able to boot.
>
> I was hoping for some more specific information than that.

I don't think anyone has tested any of this on voyager.  The hard
part is generally in the boot up code not the code on the kexec
path.

Since voyager is so weird I haven't a clue what the real state
of affairs is there.

>> >> Hopefully we can figure out how to initialize apics in init_IRQ
>> >> and remove the need to disable io_apics and this dependency.
>> >
>> > That does sound nice. Do you have any ideas on how that could be 
>> > made to happen?
>> 
>> My patch for that got reverted because it wouldn't boot on Linus's
>> SMP laptop.  It appeared to be some weird ACPI problem.  I didn't
>> receive any bug reports otherwise.
>
> Do you have a link to the patch, or a copy of it floating around?

The reverse commit was: 1e4c85f97fe26fbd70da12148b3992c0e00361fd

You should be able to dig the rest up from there.

> ACPI is the root of many evils, particularly as its bahaviour seems
> to effect many different systems, and it behaves differently on
> different machines. Perhaps the code could be cleaned up a little
> and incoporated into -mm. In my experience the best way to solve ACPI
> problems is to expose the code to as much hardware as possible.
>
>> So I suspect the steps are:
>> 1) Unify SMP and non-SMP apic initialization so it is the exact same
>>    code.
>> 2) Move the unified code up in the boot sequence into init_IRQs.
>> 
>> It is something that needs to be done very delicately.
>
> Yes undersandably so. Sounds quite tedious :(

More or less.  I don't think it is too bad it just requires a bit
of time to pursue it.  

Eric