initramfs failing, 7MB limit?

[Scott D. Davilla]

>  > This is OT but I'm seeing what seems like a 7MB limit on an initramfs
>>  under 2.6.24.3.
>>
>>  I can boot an initramfs which also works under kexec that has a cpio
>>  size of 6480384 bytes.  I have another (created the same way) that
>>  has more userland tools with a size of 7395328 bytes. That fails
>>  under both boot and kexec with the kernel not finding "/init" and
>>  panicking. "/init"  is present and executable in the initramfs. This
>>  fails on the target hardware and two other standard PC hardware with
>>  256M, 512M and 1G of RAM.
>>
>>  I use the kernel scripts (scripts/gen_initramfs_list.sh  and
>>  usr/gen_init_cpio ) to create the cpio based initramfs but it's not
>>  embedded in the kernel. It's a standalone initramfs that gets passed
>>  to the bootloader/kexec.
>>
>>  It's my understanding that with an initramfs, one is just limited to
>>  available RAM and there are no set size limits.
>>
>>  Anyone else see this behavior or am I doing something incredibly stupid.
>
>We have booted with very large initramfs (greater than 100MB) on ppc64
>and not had a problem. 
>
>You're probably having problems the initramfs overwriting some other
>important information.  What does the memory map look like?  Where is
>the initramfs located in memory and what is after it?
>

I'm not sure that's the case, this occurs independent of using a) 
kexec, b) syslinux or c) atv-bootloader on three different x86 
hardware platforms with one having three difference memory 
configurations.

I'm pretty sure kexec will place the initrd in a proper location as 
does syslinux. Since I'm writing atv-bootloader, the initrd is placed 
just under the bootloader which is loaded at 0xB000000 (darwin mach 
kernel load location). So the failure does not seem to depend on 
initial load location of the initramfs. I could track down the actual 
load locations but don't think this problem is dependent on that.

In addition, on two of the platforms, I has serial support so I can 
run a serial console to capture the kernel output of the panic'd 
load. The kernel finds the initramfs (initrd), loads it and seem 
happy with it. It then panics later when trying to run "/init". I am 
building both initrds with kernel scripts and the only difference is 
the addition of wget and support glibc libs and these are not 
referenced in the init code. So the cpio built processes should be 
ok. Unless cpio itself is barfing.

It's either something about the cpio construction or the kernel's 
unpacking. I did read something about one cannot have ext3 support as 
a compiled module or bad things happen, but that seems really goofy, 
why should the kernel be using ext3 for an initramfs, ext3 seems 
really stupid for a ram disk, what's to save?

Scott