Changes are isolated to sanitize_e820_map().
(patch is against linux-2.4.3-ac3)
This change informs the user when overlaping memory regions have been
found in their e820 map. If overlaps were found, it displays the
original mapping and then creates an adjusted map (w/o overlaps). If
no overl
Hi!
> > bios-e820: 0009f400 @ (usable)
> > bios-e820: 0c00 @ 0009f400 (reserved)
> > bios-e820: 03f0 @ 0010 (usable)
> > bios-e820: 03f0 @ 0010 (usable)
> > bios-e820: 0010
I spent some time testing the previous patch today. I found a couple of corner cases
that weren't handled correctly in the first version.
I've attached a new version (against 2.4.2-ac7) that should fix those problems.
Brian
[EMAIL PROTECTED]
--- linux-2.4.2-ac7/arch/i386/kernel/setup.cThu
I believe the following patch fixes the problem (it worked on the few machines I
tested).
Is this along the lines of what you were thinking?
Brian
[EMAIL PROTECTED]
Alan Cox wrote:
> Having been over the code the problem is indeed the bios reporting overlapping
> /duplicated ranges. That will
> memory map that hangs (added debugging to setup.S to determine E820 map):
>hand-copied physical RAM map:
> bios-e820: 0009f400 @ (usable)
> bios-e820: 0c00 @ 0009f400 (reserved)
> bios-e820: 03f0 @ 0010 (usable)
> Kernel 2.4.2-ac6 hangs while booting an AMD Elan SC520 development board.
>
> memory map that hangs (added debugging to setup.S to determine E820 map):
>hand-copied physical RAM map:
> bios-e820: 0009f400 @ (usable)
> bios-e820: 0c00 @ 00
Kernel 2.4.2-ac6 hangs while booting an AMD Elan SC520 development board.
Long-story-short
If I define "STANDARD_MEMORY_BIOS_CALL" in setup.S and misc.c, it boots
fine. Here are the results:
memory map that hangs (added debugging to setup.S to determine E820 map):
hand-copi
7 matches
Mail list logo