kernel BUG at gzip.c:3334! (2.4.23-ck1 etc)

Jorge Nerin jnerin at svalero.es
Wed Feb 25 15:50:41 UTC 2004


Ingo Molnar wrote:

>* Jorge Nerin <jnerin at svalero.es> wrote:
>
>  
>
>>Hello, I was testing the value of "2" in /proc/sys/net/tux/compression 
>>when I found that:
>>
>>Feb 24 15:17:56 head kernel: deflate in loop returned -5
>>Feb 24 15:17:56 head kernel: kernel BUG at gzip.c:3334!
>>    
>>
>
>i've uploaded a new Tux patch to:
>
>	redhat.com/~mingo/TUX-patches/tux3-2.6.3-B2
>
>i've fixed all bugs in the gzip code i could find: made it use the 2.6
>kernel's deflate library, and fixed a couple of bad assumptions. Memory
>consumption should be lower as well, since now deflate state is
>per-Tux-thread, not per-request. I've added the gzip fix from Miles Elam
>as well.
>
>i've done light testing with compression=2, but YMMV - does it work for
>you?
>
>i suspect the compression level should be configurable as well. Right
>now it's hardcoded to level 6 - what level would be the best?
>
>(this patch includes some more fixes as well - eg. stack footprint
>reduction for CGIs.).
>
>	Ingo
>  
>
I still can't upgrade to 2.6, this box has a beta redhat 6.9.5 heavily 
tweaked and I can't seem to find the time to upgrade to 2.6 (the glibc 
threads upgrade scares me), if you can make a patch to 2.4 I will try it.

About the compression level, the easy answer is to make it a 
configurable value, either at compile time, or better like a proc entry, 
but I find that 6 is a good answer, althougth the cvs folks always 
recomends 3.

-- 
Jorge Nerin
<coma at redvip.homelinux.net>





More information about the tux-list mailing list