From wms at igoweb.org Sun Sep 3 09:20:37 2006 From: wms at igoweb.org (William M. Shubert) Date: Sun, 03 Sep 2006 02:20:37 -0700 Subject: Tux Crash (same as Thierry dM's?) Message-ID: <1157275237.12604.170.camel@desktop.igoweb.org> Running RHEL4, I today got my first ever Tux kernel panic. I've been running Tux on RHEL3 with SMP for a few years with no problem, today was the first day with any significant load on RHEL4 for me. I had the 2.6.9-42.0.2.ELsmp kernel (very latest one from Red Hat). My crash looks very much (exactly?) like the ones that Thierry de Montaudry had in July. People told him to switch to uniprocessor, but then he reported the same problem. Thierry, were you ever able to find a fix? Is Tux even being maintained by Red Hat any more? Or should I say goodbye to Tux and switch to some other web server for my static content? Tux has been great for me in the past, good performance with very low resource consumption, but of course stability is the most important thing. Here's the pertinent data from /var/log/messages, note that tux_schedule_atom called do_send_abuf which tried to dereference a null pointer: Sep 3 08:06:22 www2 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000024 Sep 3 08:06:22 www2 kernel: printing eip: Sep 3 08:06:22 www2 kernel: f8bc5e9f Sep 3 08:06:22 www2 kernel: *pde = 36b2b001 Sep 3 08:06:22 www2 kernel: Oops: 0002 [#1] Sep 3 08:06:22 www2 kernel: SMP Sep 3 08:06:22 www2 kernel: Modules linked in: nfsd exportfs md5 ipv6 parport_pc lp parport tux zlib_deflat\e autofs4 i2c_dev i2c_core nfs lockd nfs_acl sunrpc ipt_multiport iptable_filter ip_tables dm_mirror dm_mod \button battery ac uhci_hcd ehci_hcd hw_random snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm \snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore e100 mii e1000 floppy ext3\ jbd ata_piix libata sd_mod scsi_mod Sep 3 08:06:22 www2 kernel: CPU: 1 Sep 3 08:06:22 www2 kernel: EIP: 0060:[] Not tainted VLI Sep 3 08:06:22 www2 kernel: EFLAGS: 00010246 (2.6.9-42.0.2.ELsmp) Sep 3 08:06:22 www2 kernel: EIP is at do_send_abuf+0xa1/0x17c [tux] Sep 3 08:06:22 www2 kernel: eax: 00000000 ebx: f66d6380 ecx: 00004040 edx: 00000000 Sep 3 08:06:22 www2 kernel: esi: 00000000 edi: f66d64b4 ebp: f66d6380 esp: f717ef10 Sep 3 08:06:22 www2 kernel: ds: 007b es: 007b ss: 0068 Sep 3 08:06:22 www2 kernel: Process tux (pid: 3194, threadinfo=f717e000 task=c2bf4e30) Sep 3 08:06:22 www2 kernel: Stack: 00000000 f66d6380 00000000 f8bd543c 00000003 f8bb902e f66d6380 f66d63a8 Sep 3 08:06:22 www2 kernel: f8bb9d09 f717ef4c f8bd543c 00000000 00000000 f717e000 f8bc378d 00000000 Sep 3 08:06:22 www2 kernel: 00000005 00000005 f8bc522a c0166484 00000000 c0159f84 c2b162ac f8bd543c Sep 3 08:06:22 www2 kernel: Call Trace: Sep 3 08:06:22 www2 kernel: [] tux_schedule_atom+0x2a/0x42 [tux] Sep 3 08:06:22 www2 kernel: [] process_requests+0x93/0xa8 [tux] Sep 3 08:06:22 www2 kernel: [] event_loop+0x75/0x178 [tux] Sep 3 08:06:22 www2 kernel: [] __sys_tux+0x366/0x88f [tux] Sep 3 08:06:22 www2 kernel: [] path_release+0xa/0x2d Sep 3 08:06:22 www2 kernel: [] sys_chdir+0x57/0x5f Sep 3 08:06:22 www2 kernel: [] sys_setuid+0xfc/0x108 Sep 3 08:06:22 www2 kernel: [] syscall_call+0x7/0xb Sep 3 08:06:22 www2 kernel: Code: ff ff 5f 89 c2 58 89 73 18 85 d2 79 79 83 fa f5 74 4a c6 85 e8 03 00 00 0\3 8b 45 6c 31 d2 c7 45 04 00 00 00 00 8d bd 34 01 00 00 40 24 00 00 00 00 c7 40 28 00 00 00 00 8b 85 34\ 01 00 00 e8 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From keskinege at gmail.com Sun Sep 3 20:44:58 2006 From: keskinege at gmail.com (Kursad Keskinege) Date: Sun, 3 Sep 2006 23:44:58 +0300 Subject: Tux Crash (same as Thierry dM's?) In-Reply-To: <1157275237.12604.170.camel@desktop.igoweb.org> References: <1157275237.12604.170.camel@desktop.igoweb.org> Message-ID: <99f30dbd0609031344p5058c9bco964380677de113a@mail.gmail.com> i have stopped using tux as a web front end, since no support/interest in it already. similar crashes can be simulated with: 1. get some requests pending/running to tux 2. try restart tux a crash will arise imm. according to my tests, on static small files thttpd + keep alive patch does give similar performance figures to tux, just my 5 cent idea and experience to share, kursad On 9/3/06, William M. Shubert wrote: > > Running RHEL4, I today got my first ever Tux kernel panic. I've been > running Tux on RHEL3 with SMP for a few years with no problem, today was the > first day with any significant load on RHEL4 for me. > > I had the 2.6.9-42.0.2.ELsmp kernel (very latest one from Red Hat). My > crash looks very much (exactly?) like the ones that Thierry de Montaudry had > in July. People told him to switch to uniprocessor, but then he reported the > same problem. Thierry, were you ever able to find a fix? Is Tux even being > maintained by Red Hat any more? Or should I say goodbye to Tux and switch to > some other web server for my static content? Tux has been great for me in > the past, good performance with very low resource consumption, but of course > stability is the most important thing. > > Here's the pertinent data from /var/log/messages, note that > tux_schedule_atom called do_send_abuf which tried to dereference a null > pointer: > > Sep 3 08:06:22 www2 kernel: Unable to handle kernel NULL pointer > dereference at virtual address 00000024 > Sep 3 08:06:22 www2 kernel: printing eip: > Sep 3 08:06:22 www2 kernel: f8bc5e9f > Sep 3 08:06:22 www2 kernel: *pde = 36b2b001 > Sep 3 08:06:22 www2 kernel: Oops: 0002 [#1] > Sep 3 08:06:22 www2 kernel: SMP > Sep 3 08:06:22 www2 kernel: Modules linked in: nfsd exportfs md5 ipv6 > parport_pc lp parport tux zlib_deflat\e autofs4 i2c_dev i2c_core nfs lockd > nfs_acl sunrpc ipt_multiport iptable_filter ip_tables dm_mirror dm_mod > \button battery ac uhci_hcd ehci_hcd hw_random snd_intel8x0 snd_ac97_codec > snd_pcm_oss snd_mixer_oss snd_pcm \snd_timer snd_page_alloc snd_mpu401_uart > snd_rawmidi snd_seq_device snd soundcore e100 mii e1000 floppy ext3\ jbd > ata_piix libata sd_mod scsi_mod > Sep 3 08:06:22 www2 kernel: CPU: 1 > Sep 3 08:06:22 www2 kernel: EIP: 0060:[] Not tainted VLI > Sep 3 08:06:22 www2 kernel: EFLAGS: 00010246 (2.6.9-42.0.2.ELsmp) > Sep 3 08:06:22 www2 kernel: EIP is at do_send_abuf+0xa1/0x17c [tux] > Sep 3 08:06:22 www2 kernel: eax: 00000000 ebx: f66d6380 ecx: > 00004040 edx: 00000000 > Sep 3 08:06:22 www2 kernel: esi: 00000000 edi: f66d64b4 ebp: > f66d6380 esp: f717ef10 > Sep 3 08:06:22 www2 kernel: ds: 007b es: 007b ss: 0068 > Sep 3 08:06:22 www2 kernel: Process tux (pid: 3194, threadinfo=f717e000 > task=c2bf4e30) > Sep 3 08:06:22 www2 kernel: Stack: 00000000 f66d6380 00000000 f8bd543c > 00000003 f8bb902e f66d6380 f66d63a8 > Sep 3 08:06:22 www2 kernel: f8bb9d09 f717ef4c f8bd543c 00000000 > 00000000 f717e000 f8bc378d 00000000 > Sep 3 08:06:22 www2 kernel: 00000005 00000005 f8bc522a c0166484 > 00000000 c0159f84 c2b162ac f8bd543c > Sep 3 08:06:22 www2 kernel: Call Trace: > Sep 3 08:06:22 www2 kernel: [] tux_schedule_atom+0x2a/0x42 > [tux] > Sep 3 08:06:22 www2 kernel: [] process_requests+0x93/0xa8 > [tux] > Sep 3 08:06:22 www2 kernel: [] event_loop+0x75/0x178 [tux] > Sep 3 08:06:22 www2 kernel: [] __sys_tux+0x366/0x88f [tux] > Sep 3 08:06:22 www2 kernel: [] path_release+0xa/0x2d > Sep 3 08:06:22 www2 kernel: [] sys_chdir+0x57/0x5f > Sep 3 08:06:22 www2 kernel: [] sys_setuid+0xfc/0x108 > Sep 3 08:06:22 www2 kernel: [] syscall_call+0x7/0xb > Sep 3 08:06:22 www2 kernel: Code: ff ff 5f 89 c2 58 89 73 18 85 d2 79 79 > 83 fa f5 74 4a c6 85 e8 03 00 00 0\3 8b 45 6c 31 d2 c7 45 04 00 00 00 00 8d > bd 34 01 00 00 40 24 00 00 00 00 c7 40 28 00 00 00 00 8b 85 34\ 01 00 > 00 e8 > > > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at mailhub.co.za Mon Sep 4 08:27:33 2006 From: thierry at mailhub.co.za (Thierry de Montaudry) Date: Mon, 04 Sep 2006 10:27:33 +0200 Subject: Tux Crash (same as Thierry dM's?) In-Reply-To: <1157275237.12604.170.camel@desktop.igoweb.org> Message-ID: <200609040827.k848RNhx030383@maginot.burotel.lan> Hi, I couldn't make it work with Tux, so I had to switch back to apache. It is a pity because it is the best to do that kind of job, but with some heavy tuning I managed to get apache to be almost as good as Tux, and at least to do the job I wanted it to do (mainly removing all modules I didn't need, means all of them but 2 of them, and tuning all the server's limits, + the very important flag EnableSendfile which should be turned on). Regards... and good luck, Thierry On Sun, 03 Sep 2006 02:20:37 -0700, William M. Shubert wrote: Running RHEL4, I today got my first ever Tux kernel panic. I've been running Tux on RHEL3 with SMP for a few years with no problem, today was the first day with any significant load on RHEL4 for me. I had the 2.6.9-42.0.2.ELsmp kernel (very latest one from Red Hat). My crash looks very much (exactly?) like the ones that Thierry de Montaudry had in July. People told him to switch to uniprocessor, but then he reported the same problem. Thierry, were you ever able to find a fix? Is Tux even being maintained by Red Hat any more? Or should I say goodbye to Tux and switch to some other web server for my static content? Tux has been great for me in the past, good performance with very low resource consumption, but of course stability is the most important thing. Here's the pertinent data from /var/log/messages, note that tux_schedule_atom called do_send_abuf which tried to dereference a null pointer: ... >_______________________________________________ >tux-list mailing list >tux-list at redhat.com >https://www.redhat.com/mailman/listinfo/tux-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From keskinege at gmail.com Mon Sep 4 08:29:36 2006 From: keskinege at gmail.com (Kursad Keskinege) Date: Mon, 4 Sep 2006 11:29:36 +0300 Subject: Tux Crash (same as Thierry dM's?) In-Reply-To: <200609040827.k848RNhx030383@maginot.burotel.lan> References: <1157275237.12604.170.camel@desktop.igoweb.org> <200609040827.k848RNhx030383@maginot.burotel.lan> Message-ID: <99f30dbd0609040129l58f81de8qba4fd131cbcf10ce@mail.gmail.com> hi thierry, can you share your apache config for tuning? thanks a lot, k. On 9/4/06, Thierry de Montaudry wrote: > > Hi, > > I couldn't make it work with Tux, so I had to switch back to apache. It is > a pity because it is the best to do that kind of job, but with some heavy > tuning I managed to get apache to be almost as good as Tux, and at least to > do the job I wanted it to do (mainly removing all modules I didn't need, > means all of them but 2 of them, and tuning all the server's limits, + the > very important flag EnableSendfile which should be turned on). > > Regards... and good luck, > > Thierry > > > On Sun, 03 Sep 2006 02:20:37 -0700, William M. Shubert wrote: > > Running RHEL4, I today got my first ever Tux kernel panic. I've been > running Tux on RHEL3 with SMP for a few years with no problem, today was > the first day with any significant load on RHEL4 for me. > > I had the 2.6.9-42.0.2.ELsmp kernel (very latest one from Red Hat). My > crash looks very much (exactly?) like the ones that Thierry de Montaudry > had in July. People told him to switch to uniprocessor, but then he > reported the same problem. Thierry, were you ever able to find a fix? Is > Tux even being maintained by Red Hat any more? Or should I say goodbye > to Tux and switch to some other web server for my static content? Tux > has been great for me in the past, good performance with very low > resource consumption, but of course stability is the most important > thing. > > Here's the pertinent data from /var/log/messages, note that > tux_schedule_atom called do_send_abuf which tried to dereference a null > pointer: > > ... > > >_______________________________________________ > >tux-list mailing list > >*tux-list at redhat.com* > >*https://www.redhat.com/mailman/listinfo/tux-list* > > > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyrian at ore.org Tue Sep 5 14:15:57 2006 From: kyrian at ore.org (Kyrian) Date: Tue, 05 Sep 2006 15:15:57 +0100 Subject: notes on thttpd/lighttpd Re: Tux Crash (same as Thierry dM's?) In-Reply-To: <20060904160022.67BC47327D@hormel.redhat.com> References: <20060904160022.67BC47327D@hormel.redhat.com> Message-ID: <44FD869D.5050608@ore.org> Folks, I'd dearly like to get these TUX bugs fixed myself, but don't have the slightest idea where to start. Anyways, I've tried thttpd, and lighttpd on various different installations having abandoned TUX, and I've found both to be more than adequate at solving the Apache+PHP memory consumption issue, by offloading content to them. Speed is nothing to grumble about either. However two things of likely operational interest that I noted were: thttpd barfs on slightly malformed urls, eg. for: http://thttpd.mysite.com/images/mysite.gif It would barf on: http://thttpd.mysite.com//images/mysite.gif ... and refuse to serve the image. Although it wouldn't crash out and totally kill your server ;-) Also, I don't think thttpd has any equivalent behaviour to Apache's 'mod_status', where Lighttpd does have vaguely equivalent behaviour. K. > according to my tests, on static small files thttpd + keep alive patch > does give similar performance figures to tux, > > just my 5 cent idea and experience to share, From keskinege at gmail.com Tue Sep 5 19:54:42 2006 From: keskinege at gmail.com (Kursad Keskinege) Date: Tue, 5 Sep 2006 22:54:42 +0300 Subject: notes on thttpd/lighttpd Re: Tux Crash (same as Thierry dM's?) In-Reply-To: <44FD869D.5050608@ore.org> References: <20060904160022.67BC47327D@hormel.redhat.com> <44FD869D.5050608@ore.org> Message-ID: <99f30dbd0609051254m7a8e733at2a2d8d11916139f3@mail.gmail.com> my 5 cents: 1. apache + php seems to be the best alternative currently to serve php, i also tried lighttpd, but did not go much since i need some more modules, that needing more configuration, and stopped 2. on static files, i tried, tux, thttpd, lighttpd all comparable, but keep in mind that thttpd must be patched (i think the best one is 2.21b branch) to solve these issues + performance increase, thttpd is very near to tux performance, I never suggest thttpd to serve php, it's far away from modern web application platform but yes, under normal conditions, none can beat tux, but i am really tried to change kernel, apply patch, re-install system tests to see it stable, my last condition is tux crashes in inregular times under heavy load, k. On 9/5/06, Kyrian wrote: > > Folks, > > I'd dearly like to get these TUX bugs fixed myself, but don't have the > slightest idea where to start. > > Anyways, I've tried thttpd, and lighttpd on various different > installations having abandoned TUX, and I've found both to be more than > adequate at solving the Apache+PHP memory consumption issue, by > offloading content to them. Speed is nothing to grumble about either. > > However two things of likely operational interest that I noted were: > > thttpd barfs on slightly malformed urls, eg. for: > > http://thttpd.mysite.com/images/mysite.gif > > It would barf on: > > http://thttpd.mysite.com//images/mysite.gif > > ... and refuse to serve the image. Although it wouldn't crash out and > totally kill your server ;-) > > Also, I don't think thttpd has any equivalent behaviour to Apache's > 'mod_status', where Lighttpd does have vaguely equivalent behaviour. > > K. > > > according to my tests, on static small files thttpd + keep alive patch > > does give similar performance figures to tux, > > > > just my 5 cent idea and experience to share, > > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mingo at elte.hu Thu Sep 7 12:51:31 2006 From: mingo at elte.hu (Ingo Molnar) Date: Thu, 7 Sep 2006 14:51:31 +0200 Subject: [patch] tux3-2.6.18-rc6-A0] Message-ID: <20060907125131.GA28391@elte.hu> i've released the 2.6.18-rc6-A0 Tux patch: http://redhat.com/~mingo/TUX-patches/tux3-2.6.18-rc6-A0 this is a merge to v2.6.18-rc6, plus a few fixes, such as a fix for the symlink crash that some people were seeing. Ingo From n9688111 at mail2000.com.tw Fri Sep 8 01:34:33 2006 From: n9688111 at mail2000.com.tw (JamesLee) Date: Fri, 08 Sep 2006 09:34:33 +0800 (CST) Subject: [patch] tux3-2.6.18-rc6-A0] Message-ID: <1157679273.51239.n9688111@mail2000.com.tw> Hi mingo, It is great. :-) James. -----Original message----- From:Ingo Molnar To:tux-list at redhat.com Date:Thu, 7 Sep 2006 14:51:31 +0200 Subject:[patch] tux3-2.6.18-rc6-A0] i've released the 2.6.18-rc6-A0 Tux patch: http://redhat.com/~mingo/TUX-patches/tux3-2.6.18-rc6-A0 this is a merge to v2.6.18-rc6, plus a few fixes, such as a fix for the symlink crash that some people were seeing. Ingo _______________________________________________ tux-list mailing list tux-list at redhat.com https://www.redhat.com/mailman/listinfo/tux-list From mingo at elte.hu Wed Sep 20 16:39:42 2006 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 20 Sep 2006 18:39:42 +0200 Subject: [patch] tux3-2.6.18-1 Message-ID: <20060920163942.GA28227@elte.hu> i've released the tux3-2.6.18-1 Tux patch: http://redhat.com/~mingo/TUX-patches/tux3-2.6.18-1 this is a merge to v2.6.18, plus a few lockdep related fixes, and 64-bit compiler warning eliminations. Ingo From mcd at daviesinc.com Sun Sep 24 06:30:47 2006 From: mcd at daviesinc.com (Chris Davies) Date: Sun, 24 Sep 2006 02:30:47 -0400 Subject: [patch] tux3-2.6.18-1 In-Reply-To: <20060920163942.GA28227@elte.hu> References: <20060920163942.GA28227@elte.hu> Message-ID: <45162617.9090101@daviesinc.com> magnificent. works on P3/uniprocessor, P3/smp, P4/SMP & P4/smt without the segfaults that we experienced before on SMP/SMT machines. Haven't tested on the core2duo in 64 bit mode, but, I imagine the old segfaults should be gone. Now we can migrate our 2.4/SMP/Tux machines to 2.6. Thank you! Thank you! Thank you! Ingo Molnar wrote: > i've released the tux3-2.6.18-1 Tux patch: > > http://redhat.com/~mingo/TUX-patches/tux3-2.6.18-1 > > this is a merge to v2.6.18, plus a few lockdep related fixes, and 64-bit > compiler warning eliminations. From williama_lovaton at coomeva.com.co Mon Sep 25 12:46:38 2006 From: williama_lovaton at coomeva.com.co (William Lovaton) Date: Mon, 25 Sep 2006 07:46:38 -0500 Subject: [patch] tux3-2.6.18-1 In-Reply-To: <45162617.9090101@daviesinc.com> References: <20060920163942.GA28227@elte.hu> <45162617.9090101@daviesinc.com> Message-ID: <1159188399.28123.4.camel@nalwalovaton.coomeva.nal> Hi, I am really willing to test this but unfortunantely there I am using Fedora Core 3 because my web app need PHP 4.3 and I can't upgrade to PHP 5.1 right now. But what I am going to do is install my servers with RHEL 4 AS... Ingo, any idea if this fixes are going to be backported to RHEL 4? into some kind of kernel update? That way I can test this with my ultra loaded web server. Thanx, -William El dom, 24-09-2006 a las 02:30 -0400, Chris Davies escribi?: > magnificent. > > works on P3/uniprocessor, P3/smp, P4/SMP & P4/smt without the segfaults > that we experienced before on SMP/SMT machines. Haven't tested on the > core2duo in 64 bit mode, but, I imagine the old segfaults should be > gone. Now we can migrate our 2.4/SMP/Tux machines to 2.6. > > Thank you! Thank you! Thank you! > > Ingo Molnar wrote: > > i've released the tux3-2.6.18-1 Tux patch: > > > > http://redhat.com/~mingo/TUX-patches/tux3-2.6.18-1 > > > > this is a merge to v2.6.18, plus a few lockdep related fixes, and 64-bit > > compiler warning eliminations. > > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list