All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.