|
From: <ebi...@ln...> - 2001-06-17 23:37:46
|
Tim Small <ti...@di...> writes: > ke...@us... <mailto:ke...@us...> wrote: > > >>We have some machines here which we are using Etherboot/ mknbi to boot > >>remotely. The machines have 1G of RAM, and are failing to boot from an > >>initrd image because mknbi appears to be shoving it too high up in > >>memory. I'm going to have a go at fixing it, but my x86 assembly skills > >>are pretty much non-existant ;-). Here's what the bootup log says: > >> > >>Linux version 2.4.5 (ro...@vi... <mailto:ro...@vi...>) (gcc > version 2.95.4 20010319 > > >>(Debian prerelease)) #1941 SMP Tue Jun 12 13:07:35 BST 2001 > >>BIOS-provided physical RAM map: > >>BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) > >>BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) > >>BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > >>BIOS-e820: 0000000000100000 - 000000003fff0000 (usable) > >>BIOS-e820: 000000003fff0000 - 000000003fff8000 (ACPI data) > >>BIOS-e820: 000000003fff8000 - 0000000040000000 (ACPI NVS) > >>BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) > >>BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > >>BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) > >>127MB HIGHMEM available. > >> > >>.... > >> > >>initrd extends beyond end of memory (0x3fff0000 > 0x38000000) > >>disabling initrd > >> > >>... > >> > >>Memory: 1028240k/1048512k available (1368k kernel code, 19884k reserved, > >>479k data, 240k init, 131008k highmem) > >> > > > >What's probably happening is that first32.linux's algorithm for working > >out the memory size is not sufficiently comprehensive. The Linux kernel > >tries a few BIOS calls, first32.linux only uses two (of which e820 is > >not one) and probably doesn't take into account the holes. > >start32.S:memsize is probably what needs to be enhanced, using the code > >in the kernel's setup.S as a guide. > > > I'm pretty sure the later is beyond me. I'm also not sure it would fix > the problem, as the kernel then makes a decision about where it > considers highmem to start, and won't like the initrd being above this. > I could probably manage a dirty hack to make sure it doesn't get moved > to beyond 512M (or 768M - or some other semi-arbitary number - with 512M > of RAM, this box boots fine) - but I would imagine this is not of much > interest to anyone but myself ;-). Actually I have run into similiar problems. On a machine with 2GB of RAM with linux-2.2.x. If I place the ramdisk at I think it was 16MB it gets overwritten, because of all of the struct page entries. I have different implementation of mknbi though, and I have just hardwired my ramdisks at the top of 64MB. The 1GB/3GB split in the kernel is the wose case linux should see. So I would limit a ramdisk to either 768M or 256M. If you are moving it up in memory. For 2.4.x however, the kernel has the appropriate logic to not stomp on an initial ramdisk, before it starts allocating ram, so the fix might simply be to place the ramdisk immediately after the kernel. Eric |
