lkml.org 
[lkml]   [2002]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [ANNOUNCE][CFT] kexec for v2.5.48 && kexec-tools-1.7 -- Success Story!
From
Date
Andy Pfiffer <andyp@osdl.org> writes:

> On Tue, 2002-11-19 at 02:25, Eric W. Biederman wrote:
> > > Complete kernel boot-up log attached below. I'm going to try to find my
> > > other 576MB of RAM with the right command-line magic... ;^)
> >
> > Or you can write a routine to gather that information dynamically and send
> > me a patch for /sbin/kexec. Though it may take another proc file to do
> > that one properly.
> >
> > Eric
>
> Just to make sure I understand the problem. Until we can make all
> boot-time BIOS calls work, we need a way to:

A small clarification. BIOS calls will never work 100%. Especially in the
interesting cases like kexec on panic. So entering the kernel in
32bit mode will continue to be the default mode of. This means the
final solution to problems like this needs to be a good one.

> 1) capture the initial memory map used by the kernel, and
> 2) a way to supply that information to the to-be-run image.
>
> On my system, the e820 map looks like this (from full reboot):
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
> BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 0000000027fed140 (usable)
> BIOS-e820: 0000000027fed140 - 0000000027ff0000 (ACPI data)
> BIOS-e820: 0000000027ff0000 - 0000000028000000 (reserved)
> BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
> 639MB LOWMEM available.
>
> And /proc/iomem looks like this:
> 00000000-0009dbff : System RAM
> 0009dc00-0009ffff : reserved
> 000a0000-000bffff : Video RAM area
> 000c0000-000c7fff : Video ROM
> 000ca000-000cb7ff : Extension ROM
> 000cb800-000cffff : Extension ROM
> 000f0000-000fffff : System ROM
> 00100000-27fed13f : System RAM
> 00100000-00309f9a : Kernel code
> 00309f9b-003d873f : Kernel data
> 27fed140-27feffff : ACPI Tables
> 27ff0000-27ffffff : reserved
> effff000-efffffff : Adaptec AIC-7892P U160/m
> effff000-efffffff : aic7xxx
> f0000000-f7ffffff : S3 Inc. Savage 4
> fea00000-feafffff : Intel Corp. 82557/8/9 [Ethernet
> fea00000-feafffff : e100
> feb7e000-feb7efff : ServerWorks OSB4/CSB5 USB Contro
> feb7f000-feb7ffff : Intel Corp. 82557/8/9 [Ethernet
> feb7f000-feb7ffff : e100
> feb80000-febfffff : S3 Inc. Savage 4
> fec00000-ffffffff : reserved
>
> Comparing the two:
> Range e820 /proc/iomem
> 0000000-0009dbff usable System RAM
> 0100000-27fed140 usable System RAM
>
> >From a sample of 1 system, it looks like we should be able to use any
> ranges marked as "System RAM" that are listed /proc/iomem. Did I miss
> something?

Only that /proc/iomem is only useful this way on x86 and that
it doesn't capture the details of the memory map above 4GB. But
it is much better than only having 4GB of main memory.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [from the cache]
©2003-2011 Jasper Spaans