From: Khalid Aziz <khalid_aziz@hp.com>
To: Zou Nan hai <nanhai.zou@intel.com>
Cc: Fastboot mailing list <fastboot@lists.osdl.org>,
Linux ia64 <linux-ia64@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Luck, Tony" <tony.luck@intel.com>
Subject: Re: [PATCH] kexec for ia64
Date: Tue, 14 Mar 2006 16:08:04 +0000 [thread overview]
Message-ID: <1142352485.18421.11.camel@lyra.fc.hp.com> (raw)
In-Reply-To: <1142318909.2545.4.camel@linux-znh>
On Tue, 2006-03-14 at 14:48 +0800, Zou Nan hai wrote:
> 3. Is the set ar.k0 code necessary? ar.k0 is already holding the right
> value.
Purely defensive coding to ensure new kernel does not fall on its
face :)
>
> 4. Is the VHPT disable code necessary? kernel will soon goes into
> Physical mode and the new kernel will reset VHPT walker.
Again, playing it safe. We do not want VHPT walker waking up at this
point. Instead of assuming code will not do anything that could cause
VHPT walker to wake up, it is better to just disable it. This way, if
any code makes erroneous references to a virtual address which causes
VHPT walker to make a TLB entry, it will simply get a page fault and we
can catch that. It is much harder to debug if VHPT walker silently makes
a TLB entry for an unexpected virtual address reference and then things
go wrong further down the line.
>
> 5. Is the PCI disable code too complex?
I have simplified it as much as I can. Suggestions to simplify further
would be appreciated.
>
> The overall concern is I am afraid the code is too much than
> necessary.
>
After testing this kexec code for over 10,000 iterations of kexec'ing, I
have found not shutting devices down results in many corner cases that
have been fairly hard to debug. Adding all this code to shut down as
much of the hardware as possible has resulted in much more reliable
kexec code.
--
Khalid
==================================
Khalid Aziz Open Source and Linux Organization
(970)898-9214 Hewlett-Packard
khalid.aziz@hp.com Fort Collins, CO
"The Linux kernel is subject to relentless development"
- Alessandro Rubini
next prev parent reply other threads:[~2006-03-14 16:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-13 17:39 [PATCH] kexec for ia64 Khalid Aziz
2006-03-14 6:44 ` Andrew Morton
2006-03-14 16:00 ` Khalid Aziz
2006-03-14 6:48 ` Zou Nan hai
2006-03-14 16:08 ` Khalid Aziz [this message]
2006-03-15 0:07 ` Zou Nan hai
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=1142352485.18421.11.camel@lyra.fc.hp.com \
--to=khalid_aziz@hp.com \
--cc=fastboot@lists.osdl.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nanhai.zou@intel.com \
--cc=tony.luck@intel.com \
/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