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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox