Sync this up with 2.4:

 ChangeSet@1.404.2.2  2002-05-06 21:30:10-03:00  hch@infradead.org
 [PATCH] memsetup fixes (again)

 The mem= fixes from Red Hat's tree had a small bug:
 if mem= was not actually used with the additional features, but
 int plain old way, is used the value as the size of memory it
 wants, not the upper limit.  The problem with this is that there
 is a small difference due to memory holes.

 I had one report of a person using mem= to reduce memory size for
 a broken i386 chipset thaty only supports 64MB cached and the rest
 as mtd/slram device for swap.  I got broken as the boundaries changed.



 arch/i386/kernel/setup.c |   11 ++++++-----
 1 files changed, 6 insertions(+), 5 deletions(-)

diff -puN arch/i386/kernel/setup.c~limit_regions-syncup arch/i386/kernel/setup.c
--- 25/arch/i386/kernel/setup.c~limit_regions-syncup	2003-10-15 10:15:23.000000000 -0700
+++ 25-akpm/arch/i386/kernel/setup.c	2003-10-15 10:15:23.000000000 -0700
@@ -139,22 +139,23 @@ static void __init probe_roms(void)
 	probe_extension_roms(roms);
 }
 
-static void __init limit_regions (unsigned long long size)
+static void __init limit_regions(unsigned long long size)
 {
+	unsigned long long current_addr = 0;
 	int i;
-	unsigned long long current_size = 0;
 
 	for (i = 0; i < e820.nr_map; i++) {
 		if (e820.map[i].type == E820_RAM) {
-			current_size += e820.map[i].size;
-			if (current_size >= size) {
-				e820.map[i].size -= current_size-size;
+			current_addr = e820.map[i].addr + e820.map[i].size;
+			if (current_addr >= size) {
+				e820.map[i].size -= current_addr-size;
 				e820.nr_map = i + 1;
 				return;
 			}
 		}
 	}
 }
+
 static void __init add_memory_region(unsigned long long start,
                                   unsigned long long size, int type)
 {

_