I am using RHEL4 with kernel 2.6.9. I can load this on my hardware by passing the following kernel parameter: memmap=496M at 16M, and it loads up and runs OK. If I do not use this parameter, I get a kernel panic. When I try to load the same software onto the same hardware using PXE, I add the same parameter on the server's tftpboot/pxelinux/pxelinux.cfg/default file: append initrd=some_file.gz memmap=496M at 16M On startup, the slave machine negotiates the transfer OK. The kernel transfers. The initrd transfers. The kernel uncompresses the image OK and boot starts. The kernel panics and dies with an error like "ram image not found at 0" Where has the uncompressed image gone to? Is there an offset at play here? Is pxelinux not compatible with (older) EISA based machines? My hardware is an old Compaq Proliant 5000 server. The need for a kernel memory parameter is well documented. Please see www.cpqlinux.com. Thanks for any help.
scott domars wrote:> I am using RHEL4 with kernel 2.6.9. I can load this on my hardware by > passing the following kernel parameter: memmap=496M at 16M, and it loads up > and runs OK. If I do not use this parameter, I get a kernel panic. > When I try to load the same software onto the same hardware using PXE, I > add the same parameter on the server's > tftpboot/pxelinux/pxelinux.cfg/default file: > append initrd=some_file.gz memmap=496M at 16M > > On startup, the slave machine negotiates the transfer OK. The kernel > transfers. The initrd transfers. The kernel uncompresses the image OK > and boot starts. The kernel panics and dies with an error like "ram > image not found at 0" > > Where has the uncompressed image gone to? Is there an offset at play > here? Is pxelinux not compatible with (older) EISA based machines? > My hardware is an old Compaq Proliant 5000 server. The need for a kernel > memory parameter is well documented. Please see www.cpqlinux.com. > Thanks for any help. >You're probably putting your memmap in the middle of the ramdisk. Try adding mem=496M. I don't have time to go hunting on Compaq's website, and a quick search didn't find anything. -hpa
Thank you for your reply. I should have given a more complete URL for the 3rd party compaq info site. Here it is: http://www.cpqlinux.com/memory.html I do not understand the inner workings of why the memory is reported wrongly to the kernel at boot, though.... I tried your suggestion of memmap=496M, The kernel did not see all of the memory, so the install stopped with the following error: "not enough Ram to install Centos OS". I tried the old kernel parameter mem=496M, but this gave me a kernel panic also. Of interest, "cntrl V" gave me isolinux version 2.11. If the kernel is able to uncompress the image, how can the start address of the image be lost? Surely the start was known at some stage for the uncompress to occur? Or does the booting kernel always assume a start address of 0? in which cas,e a starting offset would always be a problem... Thanks. On Sat, 2005-07-09 at 09:08 -0700, H. Peter Anvin wrote:> syslinux at zytor.com
I have more information about my hardware that could help with the problem. The machine has a memory hole from 15M to 16M that I believe is used by eisa hardware, if installed (I have no eisa hardware plugged in). The memory hole can not be disabled. In addition to this, the initrd that is passed through PXE is huge. From memory it uncompresses to 23Mb. Given the above, how does the booting kernel handle the memory allocation? In the 2.6.x kernels there is a memory exclude parameter memmap=X$Y. Can this be used to remove the 15M to 16M hole? Thanks. On Sat, 2005-07-09 at 09:08 -0700, H. Peter Anvin wrote:> syslinux at zytor.com
scott domars wrote:> I have more information about my hardware that could help with the > problem. > The machine has a memory hole from 15M to 16M that I believe is used by > eisa hardware, if installed (I have no eisa hardware plugged in). > The memory hole can not be disabled. > In addition to this, the initrd that is passed through PXE is huge. From > memory it uncompresses to 23Mb. > Given the above, how does the booting kernel handle the memory > allocation? > In the 2.6.x kernels there is a memory exclude parameter memmap=X$Y. Can > this be used to remove the 15M to 16M hole? > Thanks.It should be. -hpa
I have successfully and easily loaded RHEL4 onto my machine. The dmesg shows the following: BIOS provided physical memory map: BIOS-88: 00000000000 - 000000009F000 (usable) BIOS-88: 00000100000 - 0000001000000 (usable) This shows several points: The BIOS only supports the E88 memory call. The BIOS reports 16Mb memory only. The memory map is lacking detail that an E820 call would have provided. The kernel must have the correct memmap parameter passed to ensure all available memory is used. How does this effect pxelinux? My current version is 2.11. Will a later version give me a different/better result? Where does the kernel get loaded in memory? Does it start at 1M and go up from there? What about the initrd; where does it go? Thanks. On Mon, 2005-07-11 at 15:58 -0700, H. Peter Anvin wrote:> > > syslinux at zytor.com
Possibly Parallel Threads
- [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
- [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
- [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
- [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
- [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP