From: "H. Peter Anvin" <hpa@zytor.com>
To: Dave Jones <davej@redhat.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: mem= handling mess.
Date: Thu, 27 May 2004 14:18:07 -0700 [thread overview]
Message-ID: <40B65B0F.9090106@zytor.com> (raw)
In-Reply-To: <20040527200320.GR22630@redhat.com>
Dave Jones wrote:
> At some point in time during 2.4, parse_cmdline_early() changed
> so that it handled such boot command lines as..
>
> mem=exactmap mem=640k@0 mem=511m@1m
>
> And all was good. This change propagated forward into 2.5,
> where it sat for a while, until hpa freaked out and
> Randy Dunlap sent in cset 1.889.364.25
>
> ChangeSet 1.889.364.25 2003/03/16 23:22:16 akpm@digeo.com
> [PATCH] Fix mem= options
>
> Patch from "Randy.Dunlap" <rddunlap@osdl.org>
>
> Reverts the recent alteration of the format of the `mem=' option. This is
> because `mem=' is interpreted by bootloaders and may not be freely changed.
>
> Instead, the new functionality to set specific memory region usages is
> provided via the new "memmap=" option.
>
> The documentation for memmap= is added, and the documentation for mem= is
> updated.
>
> This is all well and good, but 2.4 never got the same treatment.
> Result ? Now users are upgrading their 2.4 systems to 2.6,
> and finding that they don't boot any more.
> (See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124312
> for example).
>
> The "`mem=' is interpreted by bootloaders and may not be freely changed."
> obviously hasn't broken the however many users of this we have in 2.4
> so I don't buy that it'll break in 2.6 either. As its now in 2.4
> (and has been there for some time), this is something that bootloaders
> will just have to live with.
>
It was changed to memmap= I thought. The command line suggested above, for
example, WILL NOT boot with any correctly operating boot loader.
Unfortunately, given its history I suspect GRUB is nowhere in that category.
I think telling people to use memmap= instead of mem= is the only sane way to
deal with this.
What is even more puzzling is that the command line used by the user in that
question is bogus, and should be *exactly* identical to "mem=512M", but the
bug report indicates that doesn't work on that machine. Thus, there is
something more seriously wrong.
-hpa
next prev parent reply other threads:[~2004-05-27 21:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-27 20:03 mem= handling mess Dave Jones
2004-05-27 21:18 ` H. Peter Anvin [this message]
2004-05-27 21:24 ` H. Peter Anvin
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=40B65B0F.9090106@zytor.com \
--to=hpa@zytor.com \
--cc=davej@redhat.com \
--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 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.