From: Zou Nan hai <nanhai.zou@intel.com>
To: linux-ia64@vger.kernel.org
Subject: Re: IA64 kexec/kdump 2.6.18-rc5 patch
Date: Tue, 12 Sep 2006 22:56:07 +0000 [thread overview]
Message-ID: <1158101767.2591.16.camel@linux-znh> (raw)
In-Reply-To: <1156837594.2598.15.camel@linux-znh>
On Wed, 2006-09-13 at 01:13, Jack Steiner wrote:
> > Hi,
> > Below is the IA64 kexec/kdump patch against 2.6.18-rc5.
> >
> ...
> > 3. put AP to a loop of hint.pause instead of call pal_halt_light.
> > diff -Nraup linux-2.6.18-rc5/arch/ia64/kernel/smp.c linux-2.6.18-rc5-kdump/arch/ia64/kernel/smp.c
> > --- linux-2.6.18-rc5/arch/ia64/kernel/smp.c 2006-06-18 09:49:35.000000000 +0800
> > +++ linux-2.6.18-rc5-kdump/arch/ia64/kernel/smp.c 2006-08-30 10:36:01.000000000 +0800
> ...
> > +void
> > +kexec_stop_this_cpu (void *func)
> > +{
> > + unsigned long pta, impl_va_bits, pal_base;
> > +
> > + /*
> > + * Remove this CPU by putting it into fake SAL rendezvous
> > + */
> > + cpu_clear(smp_processor_id(), cpu_online_map);
> > + max_xtp();
> > + ia64_eoi();
> > +
> > + /* Disable VHPT */
> > + impl_va_bits = ffz(~(local_cpu_data->unimpl_va_mask | (7UL << 61)));
> > + pta = POW2(61) - POW2(vmlpt_bits);
> > + ia64_set_pta(pta | (0 << 8) | (vmlpt_bits << 2) | 0);
> > +
> > + local_irq_disable();
> > + pal_base = __get_cpu_var(ia64_mca_pal_base);
> > + kexec_fake_sal_rendez(func, ap_wakeup_vector, pal_base);
> > +}
> > +#endif
>
> What was the reason for introducing the kexec_fake_sal_rendez() function instead of
> actually returning to the real SAL slave loop. The HOTPLUG_CPU code in play_dead()
> in arch/ia64/kernel/process.c is very similar to what is needed.
>
the fake_sal_rendez code is from Aziz to be used at time of kexec -l
if CONFIG_HOTPLUG_CPU is not defined. They are not executed at the time
of crash dump.
>
> I'm sure the problem is platform specific, but on the SN platform, the other cpus must be
> sent back to the real SAL slave loops. Otherwise, targeting of IO interrupts
> will not work correctly in the new kexec'd kernel.
>
> IO interrupts are distributed across cpus that are not in the SAL slave loop. If
> cpus are idled in the OS instead of SAL, interrrupts are incorrected targeted
> to cpus that cannot respond.
>
>
At the time of crash, neither fake nor real SAL rendez state are
entered. I just put all the other cpus into cpu_relax loop to simplify
the code. Does it work on SN2 if you call ia64_jump_to_sal at
kdump_cpu_freeze?
Thanks
Zou Nan hai
>
> -- jack
prev parent reply other threads:[~2006-09-12 22:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 7:46 IA64 kexec/kdump 2.6.18-rc5 patch Zou Nan hai
2006-08-29 19:38 ` Bjorn Helgaas
2006-08-29 22:03 ` Zou Nan hai
2006-08-30 8:27 ` Horms
2006-08-30 8:27 ` Horms
2006-08-30 8:27 ` Horms
2006-09-01 2:24 ` Horms
2006-09-12 17:13 ` Jack Steiner
2006-09-12 19:59 ` Jack Steiner
2006-09-12 20:23 ` Luck, Tony
2006-09-12 21:25 ` Jack Steiner
2006-09-12 22:56 ` Zou Nan hai [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1158101767.2591.16.camel@linux-znh \
--to=nanhai.zou@intel.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox