Horms wrote:
> On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
>>>>> void
>>>>> machine_crash_shutdown(struct pt_regs *pt)
>>>>> @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
>>>>> atomic_inc(&kdump_cpu_freezed);
>>>>> kdump_status[cpuid] = 1;
>>>>> mb();
>>>>> - if (cpuid == 0) {
>>>>> - for (;;)
>>>>> - cpu_relax();
>>>>> - } else
>>>>> +#ifdef CONFIG_HOTPLUG_CPU
>>>>> + if (cpuid != 0)
>>>>> ia64_jump_to_sal(&sal_boot_rendez_state[cpuid]);
>>>>> +#endif
>>>>> + for (;;)
>>>>> + cpu_relax();
>>>>> }
>>>> I trust ia64_jump_to_sal doesn't return.
>>> So do I. The main problem with the compilation seems to be that
>>> ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
>>> (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
>>>
>> This may cause problem on SN platform.
>> I remember SN requires cpu0 return to SAL rendez loop to do IRQ redirection.
>> However this needs SGI people to confirm...
SN needs slave cpus being returned to SAL rendez loop with the exception
of cpu0. It seems there is not a decent way to return cpu0, so we
decided to handle cpu0 in PROM. This above code change does not casue
problem on SN platform.
>
> Does this mean that CONFIG_HOTPLUG_CPU may be required for kdump
> on the SN platform?
The SN platform uses the ia64_jump_to_sal() routine.
Thanks,
- jay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
