public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Gomes Figueira <sabbath@planetarium.com.br>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org,
	Marcelo Tosatti <marcelo@conectiva.com.br>
Subject: Re: Memory detection problem in 2.4.19-rc2
Date: Tue, 23 Jul 2002 03:48:09 -0300	[thread overview]
Message-ID: <3D3CFC29.60006@planetarium.com.br> (raw)
In-Reply-To: Pine.NEB.4.44.0207201806350.16962-100000@mimas.fachschaften.tu-muenchen.de

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

Adrian Bunk wrote:

> It seems that the change Christoph introduced (from Red Hat's tree) in the
> lines around 810 (line number in -rc3) in arch/i386/kernel/setup.c didn't
> consider the case that someone want's to _in_crease the size of the memory
> by using the "mem="  parameter.
> 
> It's the following Changeset:
> 
> <--  snip  -->
> 
>    Changeset details for 1.383.2.25
> 
>    ChangeSet@1.383.2.25  2002-04-15 23:18:40-03:00  hch@infradead.org
>    all diffs
>    [PATCH] mem= command lines fixes.
>    Another patch from Red Hat's tree:
>      mem= command-line adapts itself to existing e820 values.
>      without this patch mem=xxxM ignores bios-reserved areas and uses
>      them as RAM. This patch makes the kernel skip these areas
>    arch/i386/kernel/setup.c@1.38  2001-04-05
>    21:19:09-03:00  hch@infradead.org
> 
> <--  snip  -->

Thanks for your help. I changed the code to the way it was before and it 
worked fine. I'm running 2.4.19-rc3 now. :-)

I created a patch to undo this modification in case anyone has the same 
problem, it's attached in this message.

Bye,

   Léo


  Leonardo Gomes Figueira
  sabbath@planetarium.com.br

[-- Attachment #2: patch-memparam-2.4.19-rc3 --]
[-- Type: text/plain, Size: 1175 bytes --]

--- linux/arch/i386/kernel/setup.c.original	Mon Jul 22 21:44:45 2002
+++ linux/arch/i386/kernel/setup.c	Tue Jul 23 03:38:08 2002
@@ -808,21 +808,29 @@
 				userdef = 1;
 			} else {
 				/* If the user specifies memory size, we
-				 * limit the BIOS-provided memory map to
-				 * that size. exactmap can be used to specify
-				 * the exact map. mem=number can be used to
-				 * trim the existing memory map.
+				 * blow away any automatically generated
+				 * size
 				 */
 				unsigned long long start_at, mem_size;
  
+				if (userdef == 0) {
+					/* first time in: zap the whitelist
+					 * and reinitialize it with the
+					 * standard low-memory region.
+					 */
+					e820.nr_map = 0;
+					userdef = 1;
+					add_memory_region(0, LOWMEMSIZE(), E820_RAM);
+				}
 				mem_size = memparse(from+4, &from);
-				if (*from == '@') {
+				if (*from == '@')
 					start_at = memparse(from+1, &from);
-					add_memory_region(start_at, mem_size, E820_RAM);
-				} else {
-					limit_regions(mem_size);
+				else {
+					start_at = HIGH_MEMORY;
+					mem_size -= HIGH_MEMORY;
 					userdef=1;
 				}
+				add_memory_region(start_at, mem_size, E820_RAM);
 			}
 		}
 

      reply	other threads:[~2002-07-23  6:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-20  8:07 Memory detection problem in 2.4.19-rc2 Leonardo Gomes Figueira
2002-07-20 16:26 ` Adrian Bunk
2002-07-23  6:48   ` Leonardo Gomes Figueira [this message]

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=3D3CFC29.60006@planetarium.com.br \
    --to=sabbath@planetarium.com.br \
    --cc=bunk@fs.tum.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    /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