Messages in this thread | | | Date | Wed, 28 Aug 2002 13:37:42 +0800 (SGT) | From | Jeff Chua <> | Subject | Re: [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/
| |