Re: [KEXEC][PATCH] Modified (smaller) x86 kexec hwfixes patch

From: Eric W. Biederman (
Date: Thu Feb 13 2003 - 10:09:16 EST

Suparna Bhattacharya <> writes:

> Martin Bligh came up with a simple way to fix the kernel
> to enable kexec boot from any CPU.
> Rather than picking up boot cpu information from the MP
> tables (which belong to the previous boot in the case of
> kexec), it just sets it to the cpu its starting on.
> (See the changes in arch/i386/kernel/smpboot.c)
> This simplifies the the kexec-hwfixes patch, since we
> no longer need to move to the boot cpu before stopping
> other processors. Which removes a lot of the unconditional
> patching of reboot.c and makes it less invasive, thanks to
> Martin. Also, at panic time, cpu migration is something
> that is best avoided.

I will agree with that, at least conditionally.

I figure stop_apics can be removed from the panic path.

However stopping all of the cpus does seem to be something
that is needed on the panic path. And if we stop cpus
what is wrong with cpu migration. Or can we move the halt
of the cpus into the panic kernel? That would be my real

> It would be good if someone could test this out (on SMP)
> and confirm it works fine (I tried it on a 4way).
> Eric, Do these changes look OK to you ? Did you have
> something similar in mind, when you were talking about
> enabling the kexec'd kernel to not care about which cpu
> it was running on ?

50%. The normal case needs to shutdown the way it is currently doing.
So we need to audit the code a little more.

Basically the way I see it, in the normal case the kernel is responsible
for a clean shutdown of the kernel and all it's devices. No one else
knows better how to accomplish those tasks then the drivers running the kernel.

On the other hand during a panic the recovery kernel is responsible for
everything it possibly can handle. Because we know something is broken
in the kernel calling kexec.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:47 EST