lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG] initrd >24MB corruption (fwd)

On Tue, 27 Aug 2002, Russell King wrote:

> 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.)


What I found when I ran ram18.gz and ram24.gz was ...

ram18.gz has 18MB filled of available 28MB [6MB gzipped]

ram24.gz has 24MB filled of available 28MB [8MB gzipped]

in the case of ram24.gz, "inflate_stored" from lib/inflate.c was called,
but ram18.gz never called this function ... meaning the gzipped was
corrupted during boot up for ram24.gz. Where ... I don't know.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.085 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site