[PATCH]Uncompressing Linux... Out of memory: fixed by increased HEAP_SIZE

[PATCH]Uncompressing Linux... Out of memory: fixed by increased HEAP_SIZE

[Karsten Wiese]

Hi,

booting newest 2.6.9 experimental kernels, I frequently encountered 
"Uncompressing Linux... Out of memory --System halted"
In some mail archive I found the (obvious ;-) solution: Increase HEAP_SIZE.

Here in line 122 of arch/i386/boot/compressed/misc.c this
	#define HEAP_SIZE             0x4000
instead of 
	#define HEAP_SIZE             0x3000
made 2.6.9-mm1-RT-U10.3 boot again.

0x3400 or 03800 might also do it, haven't checked.

Best,
Karsten

Re: [PATCH]Uncompressing Linux... Out of memory: fixed by increased HEAP_SIZE

[Ingo Molnar]

* Karsten Wiese <annabellesgarden@yahoo.de> wrote:

> booting newest 2.6.9 experimental kernels, I frequently encountered 
> "Uncompressing Linux... Out of memory --System halted"
> In some mail archive I found the (obvious ;-) solution: Increase HEAP_SIZE.
> 
> Here in line 122 of arch/i386/boot/compressed/misc.c this
> 	#define HEAP_SIZE             0x4000
> instead of 
> 	#define HEAP_SIZE             0x3000
> made 2.6.9-mm1-RT-U10.3 boot again.

ah! Makes sense. Did you have LATENCY_TRACE enabled? That compiles the
kernel with -pg which creates a fatter stackframe.

	Ingo

Re: [PATCH]Uncompressing Linux... Out of memory: fixed by increased HEAP_SIZE

[karsten wiese]

 --- Ingo Molnar <mingo@elte.hu> schrieb: 
> 
> > booting newest 2.6.9 experimental kernels, I frequently
> encountered 
> > "Uncompressing Linux... Out of memory --System halted"
> > In some mail archive I found the (obvious ;-) solution:
> Increase HEAP_SIZE.
> > 
> > Here in line 122 of arch/i386/boot/compressed/misc.c
> this
> > 	#define HEAP_SIZE             0x4000
> > instead of 
> > 	#define HEAP_SIZE             0x3000
> > made 2.6.9-mm1-RT-U10.3 boot again.
> 
> ah! Makes sense. Did you have LATENCY_TRACE enabled? That
> compiles the
> kernel with -pg which creates a fatter stackframe.
> 
Only the malloc() called by gunzip() called by
decompress_kernel() is influenced by this HEAP_SIZE.
gunzip()'s internal work data is stored in that heap.
This only is in effect before the kernel "really" boots,
no?
LATENCY_TRACE is indeed off, ...but can gunzip()'s heap
needs be easier answered by a fatter stackframe (at
decompression time!)?

Thanks,
Karsten


	

	
		
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 100MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de