Uncompressing broken with commit e7db7b4270

Uncompressing broken with commit e7db7b4270

[Catalin Marinas]

Hi,

For whatever reason, with commit e7db7b4270 (arm: add support for
LZO-compressed kernels) if the kernel Image goes beyond a certain size
it fails to uncompress. Reverting this commit solves the problem.
Removing some random kernel features also solves the uncompressing as
the kernel image gets smaller.

Any idea?

-- 
Catalin

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

On Thu, Jan 28, 2010 at 05:03:49PM +0000, Catalin Marinas wrote:
> Hi,
> 
> For whatever reason, with commit e7db7b4270 (arm: add support for
> LZO-compressed kernels) if the kernel Image goes beyond a certain size
> it fails to uncompress. Reverting this commit solves the problem.
> Removing some random kernel features also solves the uncompressing as
> the kernel image gets smaller.
With the same commit zImage stopped printing dots during decompression.

Something that isn't mentioned in the commit log of e7db7b4270 is that
the decompressing routine for gzip is changed.

Before lib/inflate.c was included by arch/arm/boot/compressed/misc.c,
since e7db7b4270 it's lib/decompress_inflate.c.

Maybe the new implementation needs more stack space?  If so it might
help to increase the stack size.  (This is defined in the last line of
arch/arm/boot/compressed/head.S.  If you change the value be sure to
adapt the value just before the LC1 label in the same file, too.)

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Albin Tonnerre]

On Fri, 29 Jan 2010 15:46 +0100, Uwe Kleine-K?nig wrote :
> On Thu, Jan 28, 2010 at 05:03:49PM +0000, Catalin Marinas wrote:
> > Hi,

> > For whatever reason, with commit e7db7b4270 (arm: add support for
> > LZO-compressed kernels) if the kernel Image goes beyond a certain size
> > it fails to uncompress. Reverting this commit solves the problem.
> > Removing some random kernel features also solves the uncompressing as
> > the kernel image gets smaller.
> With the same commit zImage stopped printing dots during decompression.

> Something that isn't mentioned in the commit log of e7db7b4270 is that
> the decompressing routine for gzip is changed.

> Before lib/inflate.c was included by arch/arm/boot/compressed/misc.c,
> since e7db7b4270 it's lib/decompress_inflate.c.

Indeed, that's why it stopped printing dots.

> Maybe the new implementation needs more stack space?  If so it might
> help to increase the stack size.  (This is defined in the last line of
> arch/arm/boot/compressed/head.S.  If you change the value be sure to
> adapt the value just before the LC1 label in the same file, too.)

If so, the decompressor would exit with an error message stating that it can't
allocate enough memory, so I doubt this is the cause.

However, I have to admit I have no clue as to why Catalin is experiencing this.
Maybe you could check if your kernel is compiled with CONFIG_ALIGNMENT_TRAP, and
try setting it if it's unset, just to make sure it does not try to read
something unaligned?

Anyway... Russell, would you have any hint?
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

Hello,

On Fri, Jan 29, 2010 at 04:04:15PM +0100, Albin Tonnerre wrote:
> On Fri, 29 Jan 2010 15:46 +0100, Uwe Kleine-K?nig wrote :
> > On Thu, Jan 28, 2010 at 05:03:49PM +0000, Catalin Marinas wrote:
> > > Hi,
> 
> > > For whatever reason, with commit e7db7b4270 (arm: add support for
> > > LZO-compressed kernels) if the kernel Image goes beyond a certain size
> > > it fails to uncompress. Reverting this commit solves the problem.
> > > Removing some random kernel features also solves the uncompressing as
> > > the kernel image gets smaller.
> > With the same commit zImage stopped printing dots during decompression.
> 
> > Something that isn't mentioned in the commit log of e7db7b4270 is that
> > the decompressing routine for gzip is changed.
> 
> > Before lib/inflate.c was included by arch/arm/boot/compressed/misc.c,
> > since e7db7b4270 it's lib/decompress_inflate.c.
> 
> Indeed, that's why it stopped printing dots.
I'd like to have them back.

> > Maybe the new implementation needs more stack space?  If so it might
> > help to increase the stack size.  (This is defined in the last line of
> > arch/arm/boot/compressed/head.S.  If you change the value be sure to
> > adapt the value just before the LC1 label in the same file, too.)
> 
> If so, the decompressor would exit with an error message stating that it can't
> allocate enough memory, so I doubt this is the cause.
I havn't investigated but I wonder how a stack overflow would be
detected.
 
Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Russell King - ARM Linux]

On Fri, Jan 29, 2010 at 04:04:15PM +0100, Albin Tonnerre wrote:
> If so, the decompressor would exit with an error message stating that it can't
> allocate enough memory, so I doubt this is the cause.
> 
> However, I have to admit I have no clue as to why Catalin is experiencing this.
> Maybe you could check if your kernel is compiled with CONFIG_ALIGNMENT_TRAP, and
> try setting it if it's unset, just to make sure it does not try to read
> something unaligned?

Alignment faults can't be handled in the decompressor; we have no
reliable way to setup the machine vectors at such an early stage to
trap any exceptions.

> Anyway... Russell, would you have any hint?

Absolutely none.

Uncompressing broken with commit e7db7b4270

[Albin Tonnerre]

2010/1/29 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello,
>
> On Fri, Jan 29, 2010 at 04:04:15PM +0100, Albin Tonnerre wrote:
>> On Fri, 29 Jan 2010 15:46 +0100, Uwe Kleine-K?nig wrote :
>> > Maybe the new implementation needs more stack space? ?If so it might
>> > help to increase the stack size. ?(This is defined in the last line of
>> > arch/arm/boot/compressed/head.S. ?If you change the value be sure to
>> > adapt the value just before the LC1 label in the same file, too.)
>>
>> If so, the decompressor would exit with an error message stating that it can't
>> allocate enough memory, so I doubt this is the cause.
> I havn't investigated but I wonder how a stack overflow would be
> detected.

Meh, I misread your message and thought 'malloc space' instead of
'stack size', sorry.

Regards,
-- 
Albin Tonnerre

Uncompressing broken with commit e7db7b4270

[Colin Tuckley]

> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org 
> Behalf Of Catalin Marinas

> For whatever reason, with commit e7db7b4270 (arm: add support for
> LZO-compressed kernels) if the kernel Image goes beyond a certain size
> it fails to uncompress. Reverting this commit solves the problem.
> Removing some random kernel features also solves the uncompressing as
> the kernel image gets smaller.

My experiments appear to show that the problem appears as the kernel image
grows above 2MB

When size is 2084132 (1.9MB) it boots

If I add something to make it slightly bigger (like Control Group
Support)...

then size is 2103332 (2.005MB) and it fails to uncompress.

I'm building a RealView PBX kernel for A9 (v7).

Colin


-- 
Colin Tuckley - ARM Ltd.
110 Fulbourn Rd
Cambridge, CB1 9NJ
Tel: +44 1223 400536 

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

On Fri, Jan 29, 2010 at 04:12:08PM -0000, Colin Tuckley wrote:
> > -----Original Message-----
> > From: linux-arm-kernel-bounces at lists.infradead.org 
> > Behalf Of Catalin Marinas
> 
> > For whatever reason, with commit e7db7b4270 (arm: add support for
> > LZO-compressed kernels) if the kernel Image goes beyond a certain size
> > it fails to uncompress. Reverting this commit solves the problem.
> > Removing some random kernel features also solves the uncompressing as
> > the kernel image gets smaller.
> 
> My experiments appear to show that the problem appears as the kernel image
> grows above 2MB
> 
> When size is 2084132 (1.9MB) it boots
> 
> If I add something to make it slightly bigger (like Control Group
> Support)...
> 
> then size is 2103332 (2.005MB) and it fails to uncompress.
And does increasing the stack size helps?

e.g. s/4096/8192/ in arch/arm/boot/compressed/head.S (you need to change
two lines).

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Albin Tonnerre]

On Thu, 28 Jan 2010 17:03 +0000, Catalin Marinas wrote :
> Hi,
> 
> For whatever reason, with commit e7db7b4270 (arm: add support for
> LZO-compressed kernels) if the kernel Image goes beyond a certain size
> it fails to uncompress. Reverting this commit solves the problem.
> Removing some random kernel features also solves the uncompressing as
> the kernel image gets smaller.
> 
> Any idea?

I'm going to be really busy with school for the next 2 weeks, so unless someone
has time to dig into the issue, maybe the best option would be to revert this
patch.

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

Hello,

On Mon, Feb 01, 2010 at 11:56:27PM +0100, Albin Tonnerre wrote:
> On Thu, 28 Jan 2010 17:03 +0000, Catalin Marinas wrote :
> > Hi,
> > 
> > For whatever reason, with commit e7db7b4270 (arm: add support for
> > LZO-compressed kernels) if the kernel Image goes beyond a certain size
> > it fails to uncompress. Reverting this commit solves the problem.
> > Removing some random kernel features also solves the uncompressing as
> > the kernel image gets smaller.
> > 
> > Any idea?
> 
> I'm going to be really busy with school for the next 2 weeks, so unless someone
> has time to dig into the issue, maybe the best option would be to revert this
> patch.
I'll spend some time looking into it.

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

Hello Colin,

On Fri, Jan 29, 2010 at 04:12:08PM -0000, Colin Tuckley wrote:
> > -----Original Message-----
> > From: linux-arm-kernel-bounces at lists.infradead.org 
> > Behalf Of Catalin Marinas
> 
> > For whatever reason, with commit e7db7b4270 (arm: add support for
> > LZO-compressed kernels) if the kernel Image goes beyond a certain size
> > it fails to uncompress. Reverting this commit solves the problem.
> > Removing some random kernel features also solves the uncompressing as
> > the kernel image gets smaller.
> 
> My experiments appear to show that the problem appears as the kernel image
> grows above 2MB
What do you mean saying "kernel image"?  zImage, Image, vmlinux,
arch/arm/boot/compressed/vmlinux?

So where do you place your zImage, what is zreladdr, how big is your
RAM?

I'm able to boot with an image having:

	$ git describe
	v2.6.33-rc6
	$ ls -l vmlinux arch/arm/boot/compressed/vmlinux arch/arm/boot/compressed/vmlinux arch/arm/boot/uImage arch/arm/boot/zImage 
	-rwxr-xr-x 1 ukl ptx  2493585 2010-02-02 09:53 arch/arm/boot/compressed/vmlinux
	-rwxr-xr-x 1 ukl ptx  2493585 2010-02-02 09:53 arch/arm/boot/compressed/vmlinux
	-rw-r--r-- 1 ukl ptx  2417764 2010-02-02 09:53 arch/arm/boot/uImage
	-rwxr-xr-x 1 ukl ptx  2417700 2010-02-02 09:53 arch/arm/boot/zImage
	-rwxr-xr-x 1 ukl ptx 49218631 2010-02-02 09:50 vmlinux

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Colin Tuckley]

> -----Original Message-----
> From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]

> What do you mean saying "kernel image"?  zImage, Image, vmlinux,
> arch/arm/boot/compressed/vmlinux?

It's actually a uImage (compressed image with u-boot 64 byte header).

> So where do you place your zImage, what is zreladdr, how big is your
> RAM?

It gets loaded by u-boot TFTP into RAM at the physical address of memory at 0x70000000 and we have either 512MB or 1GB of RAM depending on which system it is.

zreladdr is 0x70008000

regards,

Colin


--
Colin Tuckley - ARM Ltd.
110 Fulbourn Rd
Cambridge, CB1 9NJ
Tel: +44 1223 400536

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

Hello Colin,

On Tue, Feb 02, 2010 at 09:07:47AM +0000, Colin Tuckley wrote:
> > -----Original Message-----
> > From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
> 
> > What do you mean saying "kernel image"?  zImage, Image, vmlinux,
> > arch/arm/boot/compressed/vmlinux?
> 
> It's actually a uImage (compressed image with u-boot 64 byte header).
> 
> > So where do you place your zImage, what is zreladdr, how big is your
> > RAM?
> 
> It gets loaded by u-boot TFTP into RAM at the physical address of memory at 0x70000000 and we have either 512MB or 1GB of RAM depending on which system it is.
> 
> zreladdr is 0x70008000
That should be fine.

What is the output on your machine?  If you see "done", can you try
defining DEBUG in arch/arm/boot/compressed/head.S?

Best reagards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Catalin Marinas]

On Tue, 2010-02-02 at 09:55 +0000, Uwe Kleine-K?nig wrote:
> On Tue, Feb 02, 2010 at 09:07:47AM +0000, Colin Tuckley wrote:
> > > -----Original Message-----
> > > From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
> >
> > > What do you mean saying "kernel image"?  zImage, Image, vmlinux,
> > > arch/arm/boot/compressed/vmlinux?
> >
> > It's actually a uImage (compressed image with u-boot 64 byte header).
> >
> > > So where do you place your zImage, what is zreladdr, how big is your
> > > RAM?
> >
> > It gets loaded by u-boot TFTP into RAM at the physical address of 
> > memory at 0x70000000 and we have either 512MB or 1GB of RAM 
> > depending on which system it is.
> >
> > zreladdr is 0x70008000
> That should be fine.
> 
> What is the output on your machine?  If you see "done", can you try
> defining DEBUG in arch/arm/boot/compressed/head.S?

I don't think we were seeing any "done". Just "Uncompressing Linux ...".

I need to get back to a bigger kernel image and I'll then try to
increase the stack size in the compressed head.S.

-- 
Catalin

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

Hello Catalin,

On Tue, Feb 02, 2010 at 10:19:36AM +0000, Catalin Marinas wrote:
> On Tue, 2010-02-02 at 09:55 +0000, Uwe Kleine-K?nig wrote:
> > On Tue, Feb 02, 2010 at 09:07:47AM +0000, Colin Tuckley wrote:
> > > > -----Original Message-----
> > > > From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
> > >
> > > > What do you mean saying "kernel image"?  zImage, Image, vmlinux,
> > > > arch/arm/boot/compressed/vmlinux?
> > >
> > > It's actually a uImage (compressed image with u-boot 64 byte header).
> > >
> > > > So where do you place your zImage, what is zreladdr, how big is your
> > > > RAM?
> > >
> > > It gets loaded by u-boot TFTP into RAM at the physical address of 
> > > memory at 0x70000000 and we have either 512MB or 1GB of RAM 
> > > depending on which system it is.
> > >
> > > zreladdr is 0x70008000
> > That should be fine.
> > 
> > What is the output on your machine?  If you see "done", can you try
> > defining DEBUG in arch/arm/boot/compressed/head.S?
> 
> I don't think we were seeing any "done". Just "Uncompressing Linux ...".
> 
> I need to get back to a bigger kernel image and I'll then try to
> increase the stack size in the compressed head.S.
Can you try the patch below and report the output in the failing case?

I tried to get STAND_ALONE_DEBUG running, but the code suffered bit rot
and is far away from working.

And I think it makes sense to make sure it's not a toolchain problem.
So can you send me a config and I give you back an uImage compiled with
my toolchain?  And maybe the other way round, too?

Best regards
Uwe

---
 arch/arm/boot/compressed/head.S |    2 +-
 arch/arm/boot/compressed/misc.c |   20 ++++++++++++++++----
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 4fddc50..78ac6d2 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -241,7 +241,7 @@ not_relocated:	mov	r0, #0
 		bl	cache_on
 
 		mov	r1, sp			@ malloc space above stack
-		add	r2, sp, #0x10000	@ 64k max
+		add	r2, sp, #0x80000	@ 512KiB max
 
 /*
  * Check to see if we will overwrite ourselves.
diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
index 56a0d11..f537f8f 100644
--- a/arch/arm/boot/compressed/misc.c
+++ b/arch/arm/boot/compressed/misc.c
@@ -274,6 +274,21 @@ asmlinkage void __div0(void)
 
 #ifndef STANDALONE_DEBUG
 
+int
+decompress_flush(char *buf, unsigned int len)
+{
+	unsigned int n;
+	char *out = &output_data[output_ptr];
+
+	for (n = 0; n < len; ++n)
+		*out++ = *buf++;
+
+	putstr(".");
+	output_ptr += len;
+
+	return len;
+}
+
 unsigned long
 decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
 		unsigned long free_mem_ptr_end_p,
@@ -288,12 +303,9 @@ decompress_kernel(unsigned long output_start, unsigned long free_mem_ptr_p,
 
 	arch_decomp_setup();
 
-	tmp = (unsigned char *) (((unsigned long)input_data_end) - 4);
-	output_ptr = get_unaligned_le32(tmp);
-
 	putstr("Uncompressing Linux...");
 	decompress(input_data, input_data_end - input_data,
-			NULL, NULL, output_data, NULL, error);
+			NULL, decompress_flush, output_data, NULL, error);
 	putstr(" done, booting the kernel.\n");
 	return output_ptr;
 }
-- 
1.6.6


-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Uwe Kleine-König]

Hello,

On Wed, Feb 03, 2010 at 10:41:07AM +0100, Uwe Kleine-K?nig wrote:
> Hello Catalin,
> 
> On Tue, Feb 02, 2010 at 10:19:36AM +0000, Catalin Marinas wrote:
> > On Tue, 2010-02-02 at 09:55 +0000, Uwe Kleine-K?nig wrote:
> > > On Tue, Feb 02, 2010 at 09:07:47AM +0000, Colin Tuckley wrote:
> > > > > -----Original Message-----
> > > > > From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
> > > >
> > > > > What do you mean saying "kernel image"?  zImage, Image, vmlinux,
> > > > > arch/arm/boot/compressed/vmlinux?
> > > >
> > > > It's actually a uImage (compressed image with u-boot 64 byte header).
> > > >
> > > > > So where do you place your zImage, what is zreladdr, how big is your
> > > > > RAM?
> > > >
> > > > It gets loaded by u-boot TFTP into RAM at the physical address of 
> > > > memory at 0x70000000 and we have either 512MB or 1GB of RAM 
> > > > depending on which system it is.
> > > >
> > > > zreladdr is 0x70008000
> > > That should be fine.
> > > 
> > > What is the output on your machine?  If you see "done", can you try
> > > defining DEBUG in arch/arm/boot/compressed/head.S?
> > 
> > I don't think we were seeing any "done". Just "Uncompressing Linux ...".
> > 
> > I need to get back to a bigger kernel image and I'll then try to
> > increase the stack size in the compressed head.S.
> Can you try the patch below and report the output in the failing case?
> 
> I tried to get STAND_ALONE_DEBUG running, but the code suffered bit rot
> and is far away from working.
> 
> And I think it makes sense to make sure it's not a toolchain problem.
> So can you send me a config and I give you back an uImage compiled with
> my toolchain?  And maybe the other way round, too?
ping.

If we choose to revert e7db7b4270 we should do so before 2.6.33.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Uncompressing broken with commit e7db7b4270

[Catalin Marinas]

On Fri, 2010-02-19 at 14:21 +0000, Uwe Kleine-K?nig wrote:
> Hello,
> 
> On Wed, Feb 03, 2010 at 10:41:07AM +0100, Uwe Kleine-K?nig wrote:
> > Hello Catalin,
> >
> > On Tue, Feb 02, 2010 at 10:19:36AM +0000, Catalin Marinas wrote:
> > > On Tue, 2010-02-02 at 09:55 +0000, Uwe Kleine-K?nig wrote:
> > > > On Tue, Feb 02, 2010 at 09:07:47AM +0000, Colin Tuckley wrote:
> > > > > > -----Original Message-----
> > > > > > From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
> > > > >
> > > > > > What do you mean saying "kernel image"?  zImage, Image, vmlinux,
> > > > > > arch/arm/boot/compressed/vmlinux?
> > > > >
> > > > > It's actually a uImage (compressed image with u-boot 64 byte header).
> > > > >
> > > > > > So where do you place your zImage, what is zreladdr, how big is your
> > > > > > RAM?
> > > > >
> > > > > It gets loaded by u-boot TFTP into RAM at the physical address of
> > > > > memory at 0x70000000 and we have either 512MB or 1GB of RAM
> > > > > depending on which system it is.
> > > > >
> > > > > zreladdr is 0x70008000
> > > > That should be fine.
> > > >
> > > > What is the output on your machine?  If you see "done", can you try
> > > > defining DEBUG in arch/arm/boot/compressed/head.S?
> > >
> > > I don't think we were seeing any "done". Just "Uncompressing Linux ...".
> > >
> > > I need to get back to a bigger kernel image and I'll then try to
> > > increase the stack size in the compressed head.S.
> > Can you try the patch below and report the output in the failing case?
> >
> > I tried to get STAND_ALONE_DEBUG running, but the code suffered bit rot
> > and is far away from working.
> >
> > And I think it makes sense to make sure it's not a toolchain problem.
> > So can you send me a config and I give you back an uImage compiled with
> > my toolchain?  And maybe the other way round, too?
> ping.
> 
> If we choose to revert e7db7b4270 we should do so before 2.6.33.

Sorry I didn't get back to you earlier. Since I last reported it,
neither me nor Colin managed to reproduce it even if I increased image
size. Unfortunately I don't have the exact image that was causing the
issue.

My proposal is to leave the commit in (unless there is other obvious
bug) until it triggers again and I'll make sure that I keep the images.

BTW, there some warning with the stack frame too big when compiling the
decompression code.

-- 
Catalin