mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@in.ibm.com>
To: Amul Shah <amul.shah@unisys.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	fastboot <fastboot@lists.osdl.org>, Andi Kleen <ak@suse.de>
Subject: Re: [Fastboot] [RFC] [PATCH 2.6.19-rc4] kdump panics early in boot when reserving	MP Tables located in high memory
Date: Thu, 2 Nov 2006 18:36:29 -0500	[thread overview]
Message-ID: <20061102233629.GB18286@in.ibm.com> (raw)
In-Reply-To: <1162506272.19677.33.camel@ustr-linux-shaha1.unisys.com>

On Thu, Nov 02, 2006 at 05:24:32PM -0500, Amul Shah wrote:
> The kdump crash kernel panics when it tries to reserve the MP Config
> tables on an ES7000.
> 
> The MP Config table is located above 1MB of physical memory in a
> reserved memory area.  It is located outside the first 1MB area because
> the tables are too large, 240k.
> 

Hi Amul,

Can you tell where it is placed in your system? At the end of physical
RAM?

> The crash kernel is given a user defined memory map with E820 reserved
> and ACPI areas passed in by kexec tools and a usable area from 16MB
> physical to 80MB physical.  This user defined map causes the top of
> memory to be set as 80MB.
> 
> The ACPI tables and MP Tables reside higher in memory.  When reserving
> memory with reserve_bootmem_generic, the function has a BUG panic if the
> memory location to reserve is above the top of memory.  The MP table is
> above the top of memory in a user defined memory map.
> 
> This patch will ignore reserving the MP tables if the MP table resides
> in an area already reserved in the E820.
> 
> I have two alternate patches that accomplish the same effect if this
> patch is not acceptable.
> 1. avoid reserving the MP tables if a user defined memory map or if a
> user defined memory limit ("mem=") is used.
> 2. avoid reserving the MP tables if a kernel parameter is passed in to
> ignore MP table reservation.
> 
> 

I think both the methods are not the right way to solve the problem. It
will just fix the symtom you are facing. Currently this solution works
for you as you are using MADT tables from ACPI. But it will fail if you try
to boot second kernel on your system with acpi=off as MP tables are not
accessible.

I think the right way to fix this problem would be to let kexec-tools know
where the MP table is in RAM and kexec-tools can create another memmap=
entry for that area so that MP tables are accessible in second kernel.

I think you need to export the MP table location and size to user space,
say through /sys/kernel/. And also modify kexec-tools to parse it.

Thanks
Vivek

  reply	other threads:[~2006-11-02 23:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-02 22:24 Amul Shah
2006-11-02 23:36 ` Vivek Goyal [this message]
2006-11-03 14:30   ` [Fastboot] " Amul Shah
2006-11-03  2:40 ` Andi Kleen
2006-11-03 14:55   ` Amul Shah
2006-11-03 16:51     ` Andi Kleen
2006-11-03 17:17       ` Vivek Goyal
2006-11-03 19:47         ` Amul Shah
2006-11-03 19:52           ` Andi Kleen
2006-11-03 21:17             ` Amul Shah
2006-11-03 22:01               ` Andi Kleen
2006-11-03 17:40       ` Vivek Goyal
2006-11-03 18:43         ` Andi Kleen
2006-11-03 18:51           ` Vivek Goyal

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=20061102233629.GB18286@in.ibm.com \
    --to=vgoyal@in.ibm.com \
    --cc=ak@suse.de \
    --cc=amul.shah@unisys.com \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@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

all inboxes | Powered by JetHome®