Message-ID: <af7719af0906160127n36be4aa2qf5a309f44077b4b1@mail.gmail.com>
Date:	Tue, 16 Jun 2009 18:27:11 +1000
From:	David Lindsay <dav7@...7.net>
To:	linux-kernel@...r.kernel.org
Subject: Kernel 2.4.0 ramdisk decompression infinite loop

I know kernel 2.4.0 is old, but it's the oldest kernel my system will
compile (with binutils 2.9.1 downloaded from kernel.org/lib/ and GCC
2.95.3), and I want a small kernel. ;-)
If anyone knows how to make a (useful ;p) ~350kB 2.6, please do tell! :P

I'm using the good ol' dd-a-kernel-and-root-filesystem-to-floppy disk
method and if I compress the root filesystem the kernel fails to
unpack it... except it doesn't print an error. It just hangs, and from
what I've seen, apparently for good. I'm using gzip 1.3.12, if that
helps - did anything with gzip change between 2000 and now (2009)?

I'm not much of a debugger, but for fun I jumped into the kernel and
printk()d myself all the way to inflate.c. I know, printk() is
probably the Wrong Way(TM) to do it, but after discovering a couple of
empty debugging defines at the top of inflate.c (there are DEBGs and
to a lesser extent DEBG1s scattered throughout the code, very
thoughtful), I filled these in with...
#define DEBG(x) printk("DEBG:  %s\n", x);
#define DEBG1(x) printk("DEBG1: %s\n", x);
...and almost immediately found the likely culprit thanks to these
defines - lines 536 to 608 in inflate_codes(): what looks like a loop
apparently gone infinite. It's a for(;;) and does have a break in
there (of course), but it looks like the break condition (e = 15) is
never met in the ramdisk unpack context. Wonder why. I mean, this code
decompresses the kernel, right?

I printk()'d e: I got a few widely varied integers back then 0 forever. Weird.

http://lxr.linux.no/linux-old+v2.4.31/lib/inflate.c#L513 will send you
straight to line 513, the start of inflate_codes().

(De)compression is definitely not my field (web development, design,
ideas and *basic* C are more my forte :P) so I'm wayyy outta my league
here. Any ideas, guys?

What's important to note is that I can create and write an
/uncompressed/ ext2 filesystem to the disk and the kernel will
discover, read, and load it just fine. I haven't progressed to
actually getting a usable shell (since I'm trying to use the asmutils
(http://asm.sourceforge.net/asmutils.html) shell, but that's a
different story) but I can load uncompressed ext2 filesystems and they
do work - for example, dropping a nasm/ld'd "hello world" from off the
web into /bin/init will produce "hello world" (then the kernel will
complain that init just died).

I've taken the info I used to put my floppy creation script together
from wide and varied corners of the 'Net so, suspecting it, tried a
different script, the one that comes with the asmutils. Same problem -
if the ramdisk is compressed, it simply goes splat (ie it hangs), if
it's uncompressed it'll proceed (but not do anything useful beyond
that point).

Thanks in advance for any help you can give.

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

Powered by blists - more mailing lists