Decompression failure in an inexplicable case

Michael Cashwell mboards at prograde.net
Thu Apr 29 14:59:25 EDT 2010


On Apr 29, 2010, at 12:34 PM, Catalin Marinas wrote:

> On Thu, 2010-04-29 at 16:27 +0100, Michael Cashwell wrote:
>> If I omit CPUFreq support [CONFIG_CPU_FREQ is not set], or enable both it and its debugging support [CONFIG_CPU_FREQ_DEBUG=y], the kernel builds and runs seemingly fine.
>> 
>> But if I have CONFIG_CPU_FREQ enabled but NOT its debugging support then kernel builds OK (including full mrproper cleanings in between):
> 
> BTW, one of the suggestions at the time was to try this:
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 3dc2cf8..e12e382 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -316,7 +316,7 @@ LC0:		.word	LC0			@ r1
> 		.word	_start			@ r5
> 		.word	_got_start		@ r6
> 		.word	_got_end		@ ip
> -		.word	user_stack+4096		@ sp
> +		.word	user_stack+8192		@ sp
> LC1:		.word	reloc_end - reloc_start
> 		.size	LC0, . - LC0
> 
> @@ -1086,4 +1086,4 @@ reloc_end:
> 
> 		.align
> 		.section ".stack", "w"
> -user_stack:	.space	4096
> +user_stack:	.space	8192

OK, I tried this (with Uwe's other malloc heap size and decompress_flush() callback patches) and sadly my results were unchanged:

Bytes transferred = 1736932 (1a80e4 hex)
## Booting image at a2000000 ...
   Image Name:   2.6.33.2-gum1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1736868 Bytes =  1.7 MB
   Load Address: a1000000
   Entry Point:  a1000000
   Verifying Checksum ... OK
No initrd

Starting kernel at address a1000000 ...

Uncompressing Linux..............................................................................................................

uncompression error

 -- System halted

So there still seems to be some data-dependent issues in the kernel's gunzip decompressor.

-Mike




More information about the linux-arm-kernel mailing list