All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jurriaan <thunder7@xs4all.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Helge Hafting <helgehaf@aitel.hist.no>,
	linux-kernel@vger.kernel.org, Vivek Goyal <vgoyal@in.ibm.com>
Subject: Re: 2.6.21-rc5-mm3 - no boot, "address not 2M aligned"
Date: Sun, 01 Apr 2007 00:15:51 -0600	[thread overview]
Message-ID: <m1ircghb6w.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070401052932.GA9894@amd64.of.nowhere> (thunder7@xs4all.nl's message of "Sun, 1 Apr 2007 07:29:32 +0200")

thunder7@xs4all.nl writes:

> I had the same with this .config from 2.6.21-rc3-mm2 after running 'make
> oldconfig' and answering N to all new questions. Then, I tweaked some
> items, mostly to see if there was an 'align kernel' item in there
> somewhere. Diff between _working_ 2.6.21-rc5-mm3 .config and this
> 2.6.21-rc3-mm2 .config at the end. Somehow that seems to have adapted
> 'CONFIG_PHYSICAL_START', maybe that's it?

That looks like it.

Does anyone know how to express the constraint of a 2M aligned number in Kconfig?

The original plan was to remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE on
x86_64 because after this series they have no cost and thus just lead to a little
more confusion.

However because we don't tag vmlinux as ET_DYN and Xen has some use for kernel
built at different physical addresses (or at least loaded at them), and because
Xen directly loads vmlinux he kept those options.

If we can find a place to stick it into the build doing a little post processing
of vmlinux so that it has the proper ELF header type (ET_DYN not ET_EXEC) would
be useful and allow us to remove those extra confusing options.

If I have a spare moment I will take a look.  Since there is confusion it is
probably worth removing the unnecessary confusing options if we can instead
of supporting the full confusion.

Doing the same for i386 would be a little harder but with Dave
Miller's suggestions for Xen and leaving the functions to be replaced
unlinked so the compiler generates efficient calls and then doing
linking magic to fill in the pieces at boot looks about as tricky as
moving the relocation logic for i386 into vmlinux as well.  So it
seems feasible and possibly worth doing.

Eric

  reply	other threads:[~2007-04-01  6:16 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-30  8:05 2.6.21-rc5-mm3 Andrew Morton
2007-03-30 11:00 ` 2.6.21-rc5-mm3 Rafael J. Wysocki
2007-03-30 16:31 ` 2.6.21-rc5-mm3 Michal Piotrowski
2007-03-30 16:55   ` 2.6.21-rc5-mm3 Ingo Molnar
2007-03-30 17:19     ` 2.6.21-rc5-mm3 Michal Piotrowski
2007-03-30 16:38 ` 2.6.21-rc5-mm3 Dmitry Torokhov
2007-03-30 16:59   ` 2.6.21-rc5-mm3 Andrew Morton
2007-03-30 17:23 ` 2.6.21-rc5-mm3 Valdis.Kletnieks
2007-03-30 18:58   ` 2.6.21-rc5-mm3 Johannes Berg
2007-03-31  7:12 ` 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" Helge Hafting
2007-03-31  7:53   ` Andrew Morton
2007-03-31  8:14     ` Eric W. Biederman
2007-04-09 22:09       ` Helge Hafting
2007-04-10  4:48         ` Helge Hafting
2007-04-01  5:29     ` thunder7
2007-04-01  6:15       ` Eric W. Biederman [this message]
2007-04-01  6:29         ` Andrew Morton
2007-04-02  7:41           ` Vivek Goyal
2007-04-02  8:43             ` Eric W. Biederman
2007-04-02  9:45               ` Vivek Goyal
2007-04-02 17:26                 ` Eric W. Biederman
2007-04-03  4:01                   ` Vivek Goyal
2007-04-03  5:23                     ` Eric W. Biederman
2007-04-03 10:03                       ` Vivek Goyal
2007-04-23  5:12                         ` [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Eric W. Biederman
2007-04-23  5:12                           ` Eric W. Biederman
2007-04-23  5:15                           ` [PATCH 2/2] x86_64: Remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE Eric W. Biederman
2007-04-23  5:15                             ` Eric W. Biederman
2007-04-23  6:07                             ` Vivek Goyal
2007-04-23  6:07                               ` Vivek Goyal
2007-04-23  6:17                               ` Eric W. Biederman
2007-04-23  6:17                                 ` Eric W. Biederman
2007-04-23  6:25                                 ` Vivek Goyal
2007-04-23  6:25                                   ` Vivek Goyal
2007-04-24  6:31                           ` [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Vivek Goyal
2007-04-24  6:31                             ` Vivek Goyal
2007-04-24  7:21                             ` Eric W. Biederman
2007-04-24  7:21                               ` Eric W. Biederman
2007-04-02 11:17             ` 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" thunder7
2007-04-02 11:36               ` Vivek Goyal
2007-04-02 14:49                 ` thunder7
2007-04-02 14:59                   ` thunder7
2007-04-03  4:05                     ` Vivek Goyal
2007-03-31  8:05 ` 2.6.21-rc5-mm3 - cpuidle, acpi, and C-states Valdis.Kletnieks
2007-03-31 19:25 ` 2.6.21-rc5-mm3: Why was my vioc cleanup patch dropped? Adrian Bunk
2007-03-31 20:48 ` [-mm patch] make drivers/ata/pata_ali.c:ali_tf_load() static Adrian Bunk
2007-04-01 16:21   ` Tejun Heo
2007-03-31 20:55 ` [2.6 patch] remove the config option for the cs5530a_warm_reset() quirk Adrian Bunk
2007-03-31 21:05   ` Jeremy Fitzhardinge
2007-03-31 21:11     ` Adrian Bunk
2007-03-31 21:17       ` Jeremy Fitzhardinge
2007-03-31 20:55 ` [-mm patch] make drivers/net/qla3xxx.c:PHY_DEVICES[] static Adrian Bunk
2007-04-04  2:34   ` Jeff Garzik
2007-04-04 17:11     ` Ron Mercer
2007-03-31 20:55 ` [-mm patch] make struct proc_fdinfo_file_operations static Adrian Bunk
2007-04-01 16:00 ` 2.6.21-rc5-mm3 Michal Piotrowski
2007-04-01 19:03   ` 2.6.21-rc5-mm3 Andrew Morton
2007-04-01 20:39     ` 2.6.21-rc5-mm3 Rafael J. Wysocki
2007-04-01 20:56       ` 2.6.21-rc5-mm3 Rafael J. Wysocki
2007-04-01 21:59       ` 2.6.21-rc5-mm3 Rafael J. Wysocki

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=m1ircghb6w.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thunder7@xs4all.nl \
    --cc=vgoyal@in.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.