linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mohan Kumar M <mohan@in.ibm.com>
To: ppcdev <linuxppc-dev@ozlabs.org>
Cc: paulus@samba.org, michaele@au1.ibm.com, miltonm@bga.com
Subject: [RFC v2 PATCH 0/4] Relocatable kernel support for PPC64
Date: Mon, 7 Jul 2008 22:56:00 +0530	[thread overview]
Message-ID: <20080707172600.GE11470@in.ibm.com> (raw)

Hi,

Following four patches enable the "relocatable kernel" feature for
PPC64 kernels.
        1. extract_relocation_info.patch
        2. relocation_build.patch
        3. apply_relocation.patch
        4. relocation_support.patch

With the patchset, vmcore image of a crashed system can be captured
using the same kernel binary.

Still the kernel is not a fully relocatable kernel. It can either run at
0 or 32MB based on which address its loaded. If its loaded by 'kexec
-p',
it behaves as a relocatable kernel and runs at 32MB(even though its
compiled for 0). If the same kernel is loaded by yaboot or kexec -l, it
will behave as a normal kernel and will run at the compiled address.

Issues:
* During kdump kernel boot, all secondary processors are stuck up. But
  during yaboot all secondary processors are brought online.
* Relocatable kernel build process is not yet integrated with the kernel
  build.
* Kdump kernel boot fails on some specific systems because exception vectors
  are overwritten (When I tested the same kernel binary on an another
  machine kdump kernel boots). No issues in OpenPower and Power6 machines. I
  have faced exception overwritten problem in one Power5 lpar.

Building relocatable kernel support:
Enable "Build a kdump crash kernel" option and "Build relocatable
kernel"
options to build the kernel as relocatable.

After the kernel build, build the relocatable kernel by running
        make -f make.reloc

Copy the vmlinux.reloc to /boot, build initrd and update yaboot.conf to
include the entry for 'vmlinux.reloc' and corresponding initrd

Please give me your comments and suggestions to fix the above issues and
improve this feature.

Regards,
Mohan.

             reply	other threads:[~2008-07-07 17:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-07 17:26 Mohan Kumar M [this message]
2008-07-07 17:34 ` [RFC v2 PATCH 1/4] Extract list of relocation offsets Mohan Kumar M
2008-07-07 17:34 ` [RFC v2 PATCH 2/4] Build files needed for relocation support Mohan Kumar M
2008-07-07 17:35 ` [RFC v2 PATCH 3/4] Apply relocation info to vmlinux Mohan Kumar M
2008-07-07 17:36 ` [RFC v2 PATCH 4/4] Relocation support Mohan Kumar M

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=20080707172600.GE11470@in.ibm.com \
    --to=mohan@in.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michaele@au1.ibm.com \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).