initramfs breakage with 64-bits kernels?

initramfs breakage with 64-bits kernels?

[Florian Fainelli]

Hi all,

I have been trying to get a 2.6.29 64-bits kernel for Cavium Octeon to work 
with a 32-bits userland in an initramfs. While booting, the kernel does not 
find the initramfs due to the check against initrd_start in populate_rootfs 
(init/initramfs.c) failing.

Do you have any idea about what could be wrong here ? Is this a regression ?
-- 
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------

Re: initramfs breakage with 64-bits kernels?

[Geert Uytterhoeven]

On Thu, Apr 30, 2009 at 21:41, Florian Fainelli <florian@openwrt.org> wrote:
> I have been trying to get a 2.6.29 64-bits kernel for Cavium Octeon to work
> with a 32-bits userland in an initramfs. While booting, the kernel does not
> find the initramfs due to the check against initrd_start in populate_rootfs
> (init/initramfs.c) failing.

You mean the test for initrd_start being non-zero? Is your initramfs really at
address zero?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: initramfs breakage with 64-bits kernels?

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Geert Uytterhoeven wrote:
> On Thu, Apr 30, 2009 at 21:41, Florian Fainelli <florian@openwrt.org> wrote:
>   
>> I have been trying to get a 2.6.29 64-bits kernel for Cavium Octeon to work
>> with a 32-bits userland in an initramfs. While booting, the kernel does not
>> find the initramfs due to the check against initrd_start in populate_rootfs
>> (init/initramfs.c) failing.
>>     
>
> You mean the test for initrd_start being non-zero? Is your initramfs really at
> address zero?
I'm not set up to verify this, but I have a nagging suspicion that a
big-endian 64-bit kernel build could store an initrd_start address with
32 or fewer significant bits (i.e. it starts in the first 4GB) as a
64-bit pointer, but that the code in initramfs.c is testing the value as
a 32-bit scalar type.  I don't know about lmo but in kernel.org 2.6.29,
it's declared in include/linux/initrd.h as an extern unsigned long, not
a void *.  Little endian builds wouldn't see such a problem.

          Regards,

          Kevin K.

[-- Attachment #2: Type: text/html, Size: 1557 bytes --]

Re: initramfs breakage with 64-bits kernels?

[Kevin D. Kissell]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Kevin D. Kissell wrote:
> Geert Uytterhoeven wrote:
>> You mean the test for initrd_start being non-zero? Is your initramfs
>> really at address zero? 
> I'm not set up to verify this, but I have a nagging suspicion that a
> big-endian 64-bit kernel build could store an initrd_start address
> with 32 or fewer significant bits (i.e. it starts in the first 4GB) as
> a 64-bit pointer, but that the code in initramfs.c is testing the
> value as a 32-bit scalar type.  I don't know about lmo but in
> kernel.org 2.6.29, it's declared in include/linux/initrd.h as an
> extern unsigned long, not a void *.
And yes, I know that MIPS64 builds *should* have data type equivalence
for longs and pointers, but this behavior just smells like a data typing
mismatch problem, at some level.

          Kevin K.

[-- Attachment #2: Type: text/html, Size: 1295 bytes --]