kernel BUG at gzip.c:3334! (2.4.23-ck1 etc)
Jorge Nerin
jnerin at svalero.es
Tue Feb 24 22:12:16 UTC 2004
Hello, I was testing the value of "2" in /proc/sys/net/tux/compression
when I found that:
feb 24 15:04:32 head tux: Tux version: 3/0/0
Feb 24 15:04:32 head kernel: TUX: logger thread started.
Feb 24 15:04:32 head kernel: TUX: thread 0 listens on http://0.0.0.0:80.
feb 24 15:04:32 head tux: tux startup succeeded
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!
Feb 24 15:17:56 head kernel: invalid operand: 0000
Feb 24 15:17:56 head kernel: CPU: 0
Feb 24 15:17:57 head kernel: EIP:
0010:[lockd:nlmsvc_ops_Rc18947fa+160968/58190201] Not tainted
Feb 24 15:17:57 head kernel: EFLAGS: 00010286
Feb 24 15:17:57 head kernel: eax: 0000001c ebx: c291eee0 ecx:
00000000 edx: c705e000
Feb 24 15:17:57 head kernel: esi: c1243e00 edi: c1243e04 ebp:
00000ce8 esp: c1243db8
Feb 24 15:17:57 head kernel: ds: 0018 es: 0018 ss: 0018
Feb 24 15:17:57 head kernel: Process tux (pid: 30101, stackpage=c1243000)
Feb 24 15:17:57 head kernel: Stack: c89c9136 fffffffb c1242000 00004040
c6873f20 c89b452d c291eee0 c32ec000
Feb 24 15:17:57 head kernel: c368600b c1243e00 c1243e04 c32ec000
c3686000 c0eb6000 00000000 c1243e80
Feb 24 15:17:57 head kernel: c3c5e000 00000808 00000cb1 00000cdd
c0eb620c 0000e000 c0d1b740 000001f0
Feb 24 15:17:57 head kernel: Call Trace:
[lockd:nlmsvc_ops_Rc18947fa+173830/58177339]
[lockd:nlmsvc_ops_Rc18947fa+88829/58262340] [alloc_skb+214/416]
[do_generic_file_read+544/1312] [lockd:nlmsvc_ops_Rc18947fa+89644/58261525]
Feb 24 15:17:57 head kernel:
[lockd:nlmsvc_ops_Rc18947fa+88464/58262705]
[lockd:nlmsvc_ops_Rc18947fa+188528/58162641]
[lockd:nlmsvc_ops_Rc18947fa+109604/58241565]
[lockd:nlmsvc_ops_Rc18947fa+83464/58267705]
[lockd:nlmsvc_ops_Rc18947fa+86884/58264285]
[lockd:nlmsvc_ops_Rc18947fa+188852/58162317]
Feb 24 15:17:57 head kernel:
[lockd:nlmsvc_ops_Rc18947fa+188528/58162641]
[lockd:nlmsvc_ops_Rc18947fa+130232/58220937]
[lockd:nlmsvc_ops_Rc18947fa+188528/58162641]
[lockd:nlmsvc_ops_Rc18947fa+137866/58213303]
[lockd:nlmsvc_ops_Rc18947fa+188528/58162641]
[lockd:nlmsvc_ops_Rc18947fa+188528/58162641]
Feb 24 15:17:57 head kernel: [path_release+15/48] [sys_chdir+156/176]
[sys_tux+34/97] [system_call+51/64]
Feb 24 15:17:57 head kernel:
Feb 24 15:17:57 head kernel: Code: 0f 0b 06 0d 2f 91 9c c8 59 58 8b 43
04 89 46 00 8b 43 10 89
Feb 24 15:17:57 head kernel: <5>TUX: thread 0 stopping ...
The partition type is reiserfs, just in case it does matter, the kernel
is plain 2.4.23 with bits of the Con Kolivas patchset (O1 scheduler,
lowlatency) a patch to disable ECN after a number of retries and a patch
to correct the content-length in tux when compression is in use.
It worked ok during some time, but then it stopped with this bug, I had
to reboot. So far so good the value of "1" in compression works ok for
me (precompressed files) with a patch (that I can't remember the autor)
needed to send the correct Content-length, the compressed one instead of
the original one.
I resend the patch here, because the last time I sent it I did it with
the wrong subject and it's needed in order to enable and use compression
correctly (mozilla waits until timeout for the rest of the Content-length).
--- linux-2.4.20-ck2-tux2/net/tux/proto_http.c Wed Jan 8 08:55:07 2003
+++ linux/net/tux/proto_http.c Wed Nov 20 14:34:59 2002
@@ -1958,9 +1958,25 @@
if (partial)
curr += sprintf(curr, "%Ld", req->output_len);
else {
+ /*
// "%d" req->total_file_len
memcpy(curr, &req->etag, req->lendigits);
curr += req->lendigits;
+ */
+ /* The ETag was generated with an uncompressed file's
+ * info. I've left the ETag as it is, but the size
+ * needs to be from req->total_file_len. In other
+ * words, needs to be from the compressed image if
+ * we're sending gzip versions.
+ * - miles at geekspeak.org -- 2002-11-13
+ */
+ if (req->content_gzipped)
+ curr += sprintf(curr, "%Ld", req->total_file_len);
+ else {
+ memcpy(curr, &req->etag, req->lendigits);
+ curr += req->lendigits;
+ }
+
}
if (tux_generate_etags && (req->status != 404))
{
--
Jorge Nerin
<coma at redvip.homelinux.net>
More information about the tux-list
mailing list