Re: [BUG] initrd >24MB corruption (fwd)

[Russell King]

On Tue, Aug 27, 2002 at 04:55:00PM +0800, Jeff Chua wrote:
> On Mon, 26 Aug 2002, Erik Andersen wrote:
> > How much total ram does your system have?
> 
> 640MB.

Its not that problem then. 8)

I was suspecting that the write() to the ramdisk device was hanging
(which you could confirm by printk'ing an 'i' before and an 'o' after
the write call in flush_window() in init/do_mounts.c or
drivers/block/rd.c.  If you end up with 'i' as the last character, its
the write that hangs, if its an 'o' then its gunzip itself.)

The other possibility is this little critter:

static int __init fill_inbuf(void)
{
        if (exit_code) return -1;

        insize = read(crd_infd, inbuf, INBUFSIZ);
        if (insize == 0) return -1;

        inptr = 1;

        return inbuf[0];
}

You could put printks in the paths that return -1 and see if you're
hitting any of those.

However, returning '-1' is asking for trouble.  When I was looking at
how to handle the "out of space" in the ramdisk issue, I found that
there appears to be NO value that fill_inbuf() can return that will
guarantee to terminate inflate.c at an arbitary point in the
decompression.

In gzip, we abort the program on error.  In the kernel, we don't
have that luxury.  (Luckily initramfs uses a cut-down gzip to do
the decompression, which can exit on error.)

-- 
Russell King ([e-mail])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html