Possible bug with kernel decompressor.

Possible bug with kernel decompressor.

[Matthew Schumacher]

List,

I think I found a bug here because I can repeatably get the same kernel 
(checked with md5sum) to decompress and to fail with the error:

invalid compressed format (err=2)

   --System halted


Here is how I can reproduce the problem:

Boot 2.6.8-rc1
Run md5sum on 2.6.8-rc1 kernel
Turn power off (this is an embedded system with only ramdisk mounted)
Turn power on
Kernel fails to boot with "invalid compressed format (err=2)"
Restart system
Boot 2.4.26
Run md5sum on 2.6.8-rc1 kernel (matches md5sum above)
Shutdown properly
boot 2.6.8-rc1 (works fine)
Run md5sum on 2.6.8-rc1 kernel (matches md5sum above)

So you see if I don't shutdown properly (which shouldn't be required for 
an embedded system using a ramdisk) my kernel won't decompress itself 
until I run another kernel and shutdown properly.  I know that the 
kernel didn't change so something else must be causing it to fail.

I call this a bug simply because a power failure could cause someone to 
loose the ability to boot their machine.

Here is the hardware:
Whistle Interjet (486 SBC)
64MB of memory
IDE disk.
Can reproduce with linux  2.6.5, 2.6.6, 2.6.7, and 2.6.8-rc1
Both kernel images and the initrd image both live on a fat16 partition 
and are started with syslinux.  I can reproduce this problem with any 
version of syslinux I have tried.

Please CC me in any replies since I am not on the list.

Thanks,

schu

Re: Possible bug with kernel decompressor.

[Matthew Schumacher]

Matthew Schumacher wrote:
 > List,
 >
 > I think I found a bug here because I can repeatably get the same kernel
 > (checked with md5sum) to decompress and to fail with the error:
 >
 > invalid compressed format (err=2)
 >
 >   --System halted
 >
 >
 > Here is how I can reproduce the problem:
 >
 > Boot 2.6.8-rc1
 > Run md5sum on 2.6.8-rc1 kernel
 > Turn power off (this is an embedded system with only ramdisk mounted)
 > Turn power on
 > Kernel fails to boot with "invalid compressed format (err=2)"
 > Restart system
 > Boot 2.4.26
 > Run md5sum on 2.6.8-rc1 kernel (matches md5sum above)
 > Shutdown properly
 > boot 2.6.8-rc1 (works fine)
 > Run md5sum on 2.6.8-rc1 kernel (matches md5sum above)
 >
 > So you see if I don't shutdown properly (which shouldn't be required for
 > an embedded system using a ramdisk) my kernel won't decompress itself
 > until I run another kernel and shutdown properly.  I know that the
 > kernel didn't change so something else must be causing it to fail.
 >
 > I call this a bug simply because a power failure could cause someone to
 > loose the ability to boot their machine.
 >
 > Here is the hardware:
 > Whistle Interjet (486 SBC)
 > 64MB of memory
 > IDE disk.
 > Can reproduce with linux  2.6.5, 2.6.6, 2.6.7, and 2.6.8-rc1
 > Both kernel images and the initrd image both live on a fat16 partition
 > and are started with syslinux.  I can reproduce this problem with any
 > version of syslinux I have tried.
 >
 > Please CC me in any replies since I am not on the list.
 >
 > Thanks,
 >
 > schu
 >
 >
 >
Tim Bird wrote:
> If I recall correctly, a number of read errors during the
> initial kernel loading can result in this error message
> (which means it is somewhat misleading.)  You may have
> to add some printks to narrow this down more (in both the
> 2.4 and 2.6 kernels)
> 
> Obviously there's something in the 2.4 code that handles
> the ungracefully-shutdown machine state better than 2.6.8.
> Or there might be some other difference between the syslinux
> boot of the 2.4 kernel and that of the 2.6.8 kernel.
> 

Sorry, for the long post, I'm more doing this for the archive than 
anything else so others can google instead of ask.

I thought that this might be something with syslinux too, but didn't go 
down that road because something in the new 2.6 kernel doesn't handle 
this as gracefully as the 2.4 kernel.

That said, I thought I would try a different boot loader so I installed 
grub on the system and it seems to work fine.

I should note that this hardware requires the linux mem/memmap= params 
because of the buggy memory detection in the bios so I was required to 
use the uppermem command in grub to make it detect the memory and put 
the initrd image in the right place.

So in the end it looks like it is a syslinux issue loading the initrd 
image but for some reason the 2.4 kernel seems to be just fine with 
whatever isn't working right.

I can troubleshoot more if someone wants to track this down, but at this 
point I have a work around and now it's documented on both lists.

Thanks,

schu

Re: [syslinux] Re: Possible bug with kernel decompressor.

[H. Peter Anvin]

Matthew Schumacher wrote:
> 
> I should note that this hardware requires the linux mem/memmap= params 
> because of the buggy memory detection in the bios so I was required to 
> use the uppermem command in grub to make it detect the memory and put 
> the initrd image in the right place.
> 

Specify, please.

	-hpa

Re: Possible bug with kernel decompressor.

[Matthew Schumacher]

H. Peter Anvin wrote:
> Matthew Schumacher wrote:
> 
>>
>> I should note that this hardware requires the linux mem/memmap= params 
>> because of the buggy memory detection in the bios so I was required to 
>> use the uppermem command in grub to make it detect the memory and put 
>> the initrd image in the right place.
>>
> 
> Specify, please.
> 
>     -hpa

This is what I am using in grub and it works:

title Linux (2.6.8)
         root (hd0,0)
         uppermem 62464k
         kernel /linux26 memmap=exactmap memmap=640K@0 memmap=63M@1M 
console=ttyS0,9600n8 load_ramdisk=1 root=/dev/root ramdisk_size=32768 
ether=9,0x320,0,0x3c509,eth0 ether=10,0x330,0,0x3c509,eth1 ide0=ali14xx
	initrd /rootfs.gz

This is what I was using in syslinux that broke with "invalid compressed 
format (err=2)" after a improper shutdown (only ramdisk mounted).

  LABEL linux
   KERNEL linux26
   APPEND memmap=exactmap memmap=640K@0 memmap=63M@1M 
console=ttyS0,9600n8 load_ramdisk=1 initrd=rootfs.gz root=/dev/root 
ramdisk_size=32768 ether=9,0x320,0,0x3c509,eth0 
ether=10,0x330,0,0x3c509,eth1 ide0=ali14xx

hope that helps,

schu

Re: Possible bug with kernel decompressor.

[H. Peter Anvin]

Matthew Schumacher wrote:
> 
> This is what I was using in syslinux that broke with "invalid compressed 
> format (err=2)" after a improper shutdown (only ramdisk mounted).
> 
>  LABEL linux
>   KERNEL linux26
>   APPEND memmap=exactmap memmap=640K@0 memmap=63M@1M 
> console=ttyS0,9600n8 load_ramdisk=1 initrd=rootfs.gz root=/dev/root 
> ramdisk_size=32768 ether=9,0x320,0,0x3c509,eth0 
> ether=10,0x330,0,0x3c509,eth1 ide0=ali14xx
> 

What happens if you specify mem=64M, which should be the exact equivalent to 
the above?

	-hpa

Re: Possible bug with kernel decompressor.

[Meelis Roos]

MS> invalid compressed format (err=2)
MS> 
MS>    --System halted

I had the same on Digital Celebris 5133. One debian Woody boot floppy I
tried (don't remember which flavour) gave exactly this. Debian Sarge
boot floppies worked fine.

Additionally, lilo didn't work, just hung.

Grub does work but something (BIOS?) garbles some of the kernel command
line. I used the following kernel command line as a workaround:
abrakadabra my_real_options...
and this became
PAMSkadabra my_real_options...

Other than that it worked fine - Pentium 133, 64M RAM, onboard Adaptec
SCSI, onboard Matrox video.

-- 
Meelis Roos