|
From: <ke...@us...> - 2001-06-12 13:23:17
|
[Problem reports should always to go the mailing lists so that more brains can ponder the problem. I'm moving the discussion there.] >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...) (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. |
