From: Jack Steiner <steiner@sgi.com>
To: kexec@lists.infradead.org
Cc: mingo@elte.hu, tglx@linutronix.de, ebiederm@xmission.com,
gleb@redhat.com, suresh.b.siddha@intel.com
Subject: kdump/kexec on EFI-enabled x2apic platforms
Date: Mon, 29 Mar 2010 15:01:04 -0500 [thread overview]
Message-ID: <20100329200104.GA23760@sgi.com> (raw)
All -
I just started debugging kdump/kexec on our UV platform and
have run into some problems. I suspect others have encountered these
same or similar problems. Any help would be appreciated.
Our platform uses EFI boot. It is Nehalem based & has a large number of cpus.
The BIOS enables x2apic mode and the kernel runs with interrupt remapping enabled.
Note that some apicids have more than 8 bits - x2apic mode is required.
I am able to successfully kexec the dump kernel but run into several problems.
- because the initial kernel boots using EFI, BIOS does not build the legacy
tables that are required to locate the RSDP using the legacy method in
acpi_find_root_pointer(). (When booting with EFI, acpi_find_root_pointer() is
not used. The ACPI tables are found from pointers in EFI tables.)
- it appears that kdump/kexec intentionally boots the kdump kernel
in a mode does does enable efi mode. (Am I correct here???)
This avoids the issues with EFI virtual mode. However, the result
is that ACPI tables are not found. From the dump kernel:
ACPI Error: A valid RSDP was not found (20090903/tbxfroot-222)
- Because ACPI tables are not found, the dump kernel does not transition
into x2apic mode. The hardware, however, is still in x2apic mode from the
initial kernel. Later in the boot of the dump kernel, read_apic_id()
tried to read memory-mapped apic registers instead of the MSRs that are
used in x2apic mode. This is not allowed & the dump kernel panics with:
[ 0.000000] [<ffffffff81b52195>] early_idt_handler+0x55/0x68
[ 0.000000] [<ffffffff8101f393>] ? native_apic_mem_read+0x3/0x10
[ 0.000000] [<ffffffff8101a3c6>] ? read_apic_id+0x16/0x30
[ 0.000000] [<ffffffff81b5f857>] init_apic_mappings+0xe7/0x137
[ 0.000000] [<ffffffff81b559fd>] setup_arch+0x900/0xc33
[ 0.000000] [<ffffffff81b52bae>] start_kernel+0x6f/0x4a1
I checked an Intel Nehalem whitebox using the Intel BIOS. The dump kernel does not
find the RDSP but the initial kernel does not enable x2apic mode either (possibly
because of an old BIOS - not sure). As a result, the dump kernel does not hit
the panic shown above. The kdump kernel successfully boots w/o having discovered
ACPI tables.
How should I proceed?
- should I be running the dump kernel with EFI mode enabled?
- should I be fixing the issues with x2apic mode in a non-EFI dump kernel?
- or should BIOS be building the tables necessary to support both EFI & non-EFI boot.
--- jack
Jack Steiner (steiner@sgi.com) SGI - Silicon Graphics, Inc.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2010-03-29 20:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 20:01 Jack Steiner [this message]
2010-03-29 22:13 ` kdump/kexec on EFI-enabled x2apic platforms Eric W. Biederman
2010-03-30 17:59 ` Jack Steiner
2010-03-31 22:24 ` David N. Lombard
2010-04-01 0:47 ` Jack Steiner
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=20100329200104.GA23760@sgi.com \
--to=steiner@sgi.com \
--cc=ebiederm@xmission.com \
--cc=gleb@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
/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