Thanks, It compiled
kexec get the same error "Invalid memory segment 0x100000 - ...."
YH
"Lu, Yinghai" <[email protected]> writes:
> Thanks, It compiled
>
> kexec get the same error "Invalid memory segment 0x100000 - ...."
Could you post the entire message and the contents of /proc/iomem.
That is where the compare is happening so this may be a parsing
issue of /proc/iomem.
Eric
I found the cause before your mail.
the /proc/iomem doesn't show RAM above 1M.
I have increased linuxbios table at high 0xf0000-0xf0400 to
0xf0000-0x100000. the RAM above 1M show up.
I think root cause in the latest kernel 2.6.19, e820 align increase to 0xffff.
and when it check 0xf0000-0xf0400, will make 0xf0000-0x100000
reserved, and then when it check 0xf0400-4G, it will fail to reserved
System RAM above 1M.
I will check arch/x86_64/kernel/e820.c about
void __init e820_reserve_resources(void)
tommorrow.
YH
Andi,
On 11/9/06, yhlu <[email protected]> wrote:
> the /proc/iomem doesn't show RAM above 1M.
>
> I have increased linuxbios table at high 0xf0000-0xf0400 to
> 0xf0000-0x100000. the RAM above 1M show up.
>
Can you explain more about the patch?
I wonder what we suppose to do about [640K, 1M).
In LinuxBIOS we only set [0xa0000, 0xc0000) and [0xf0000, 0xf0400) to reserved,
[0xc0000, 0xf0000) and [0xf0400, 4G) as ram..
with your patch, the 1M above range will not show up on /proc/iomem
YH
[PATCH] Don't force reserve the 640k-1MB range
>From i386 x86-64 inherited code to force reserve the 640k-1MB area.
That was needed on some old systems.
But we generally trust the e820 map to be correct on 64bit systems
and mark all areas that are not memory correctly.
This patch will allow to use the real memory in there.
Or rather the only way to find out if it's still needed is to
try. So far I'm optimistic.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=dbf9272e863bf4b17ee8e3c66c26682b2061d40d