On Mon, 28 Aug 2000, you wrote:
> (disagree, could be wrong.. but it doesn't matter). Fact remains that top
> of memory is wrong/inconsistant with where syslinux _actually placed_ the
> initrd. empty_zero_page is a mailbox containing done deal information.
Agreed
> True IFF 2.2 uses the same BIOS interface.
Agreed
> Why do you think 31936 is any more sane than 32768 (or 3276800) as
> INITRD_START address? To get that low, the initrd would have to be so huge
> that there would be no space left for the kernel proper.
Ummm ok, symantics.. the 31936 and 32768 are in k
> You are chasing something other than the problem. Syslinux places the
> initrd at top of ram - alignment (magnitude unimportant). You have 32M
> of ram. Syslinux used it and informed you of that fact via mailbox.
Ok, let's review.....
When booting the 2.4 kernel, it detects that I have 31744K (which is equal to
32505856) of extendeded memory, as reported in setup_memory_region IF we have
a memory map (Jsut looking at PARAM + vlaues form bootloader) . This means
that we have 32M of total memory. This is correct.
The print out of the memory map shows that the top of memory is at ffff0000
which equates to ????
INITRD_SIZE=782177 which is the size of my initrd.gz file CORRECT
INITRD_START=32768000 which is the same as 32M (32*1024*1024) MINUS the
initrd.gz size (which is 33554432-782177 = 32772255) .Allowing for the offset
which in this case puts it at 13 pages, this is actually about right. At
least we are safe with INITRD_START+INITRD_SIZE (328462177) being below
33554432 (memsize)
BUT what we get is 'initrd extends beyond end of memory (0x01ffef61 >
0x1d80000, and confirming the values in this routine, we see that INITRD_START
is actually reported here as 32768000, and the initrd_size is reported as
782177, both are still the same, and both are correct.
WE are comparing to max_low_pfn << PAGE_SHIFT
(Okay, now my limited C++ experience shows, what occurs as <<PAGE_SHIFT, is
this moving a page to the next lower offset?)
Looking how this is set, we see that max_low_pfn is set via the memory_map
while all the other items including EXT_MEM_K and ALT_MEM_K are all set by
the boot loader (syslinux)
Since these values were the same in the 2.2 series, it seems that the older
kernels might have used them, or the older kernels detected the memory_map
differently.
Okay, looking into the 2.2 source we see we compare it to memory_end rather
than max_low_pfn.
Let's compare how these are arrived at. (THIS IS WHERE THINGS ARE DIFFERENT
in the 2.4 kernel series)
in the 2.2 series, memory_end is taken from (1<<20)+EXT_MEM_K, and this
worked.... Now looking at 2.4 it seems that it ignores all the data
discovered by the boot loader, and just looks at the memory_map provided by
the BIOS. So why is it getting the wrong information when a simple bootloader
can get the right information??
<Stay Tuned>
-- -------------------------------------------------------- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com -------------------------------------------------------- (604) 589-0037 Beautiful British Columbia, Canada -------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:22 EST