From bkesuma at ml.gaijinweb.com Fri Sep 3 03:05:32 2004 From: bkesuma at ml.gaijinweb.com (Batara Kesuma) Date: Fri, 3 Sep 2004 12:05:32 +0900 Subject: Maximum performance for caching Message-ID: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> Hi, I use DNS round robin to split the load to 2 Tux servers. These servers only serve image files. The image files is located on NFS server, and the Tux servers are getting the files from there. The files don't change very often, how do I get the maximum performance for caching? Right now my config files look like: ## /etc/tux.mime.types image/jpeg jpeg|86400 jpg|86400 image/gif gif|86400 image/png png|86400 ## /etc/sysctl.tux net.tux.mode_allowed = 400 net.tux.generate_etags=0 [root at ternate etc]# rpm -qa tux tux-3.2.18-1 Is it better to generate etags? Is there anything else that I can tweak the caching performance better? I asked this because my load on both servers jumped up to around 2. Thank you very much. Regards, Batara From mcd at daviesinc.com Fri Sep 3 03:09:42 2004 From: mcd at daviesinc.com (Chris Davies) Date: Thu, 02 Sep 2004 23:09:42 -0400 Subject: Maximum performance for caching In-Reply-To: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> Message-ID: <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> If the load is two, are you sure you don't have a stuck nfs handle tying things up? What tasks are in the R state? net/tux/generate_cache_control = 1 net/tux/generate_etags = 1 net/tux/generate_last_mod = 1 net/tux/defer_accept = 0 These actually do seem to make things faster based on 'seat-of-the- pants' performance. I think you can avoid last_mod with your expires header -- other than that, these are the settings we've been using for 16+ months after finally settling on what the client said was 'fast'. On Fri, 2004-09-03 at 12:05 +0900, Batara Kesuma wrote: > ## /etc/sysctl.tux > net.tux.mode_allowed = 400 > net.tux.generate_etags=0 From bkesuma at ml.gaijinweb.com Fri Sep 3 06:17:09 2004 From: bkesuma at ml.gaijinweb.com (Batara Kesuma) Date: Fri, 3 Sep 2004 15:17:09 +0900 Subject: Maximum performance for caching In-Reply-To: <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> Message-ID: <20040903151709.564803be.bkesuma@ml.gaijinweb.com> On Thu, 02 Sep 2004 23:09:42 -0400 Chris Davies wrote: > If the load is two, are you sure you don't have a stuck nfs handle > tying things up? What tasks are in the R state? How do I check this R state? And also, is there anyway I can set TUX so it caches the images in its own memory? So it doesn't need to get the file from NFS for every request. From roy at karlsbakk.net Fri Sep 3 06:52:59 2004 From: roy at karlsbakk.net (Roy Sigurd Karlsbakk) Date: Fri, 3 Sep 2004 08:52:59 +0200 Subject: Maximum performance for caching In-Reply-To: <20040903151709.564803be.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> Message-ID: >> If the load is two, are you sure you don't have a stuck nfs handle >> tying things up? What tasks are in the R state? > > How do I check this R state? ps axf or just man ps From bkesuma at ml.gaijinweb.com Fri Sep 3 07:32:07 2004 From: bkesuma at ml.gaijinweb.com (Batara Kesuma) Date: Fri, 3 Sep 2004 16:32:07 +0900 Subject: Maximum performance for caching In-Reply-To: References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> Message-ID: <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> On Fri, 3 Sep 2004 08:52:59 +0200 Roy Sigurd Karlsbakk wrote: > >> If the load is two, are you sure you don't have a stuck nfs handle > >> tying things up? What tasks are in the R state? > > > > How do I check this R state? > > ps axf > or just man ps Ok. I have checked this. Almost all of the TUX processes are in S state. apache 4753 0.0 0.0 3424 764 ? S 15:26 0:00 [TUX worker 0] apache 4754 0.0 0.0 3424 764 ? S 15:26 0:00 [TUX worker 0] apache 4755 0.0 0.0 3424 764 ? S 15:26 0:00 [TUX worker 0] apache 4756 0.0 0.0 3424 764 ? S 15:26 0:00 [TUX worker 0] apache 4757 0.0 0.0 3424 764 ? S 15:26 0:00 [TUX worker 0] But still my load average is about 2. What does this mean? This machine is dedicated to TUX server btw. The traffic is pretty huge, about 4 million pageview / day. 1 page has about 10 images, so it is about 40 million access to the images. From roy at karlsbakk.net Fri Sep 3 08:19:43 2004 From: roy at karlsbakk.net (Roy Sigurd Karlsbakk) Date: Fri, 3 Sep 2004 10:19:43 +0200 Subject: Maximum performance for caching In-Reply-To: <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> Message-ID: <024D6108-FD82-11D8-B1AC-000D936B7E6A@karlsbakk.net> >> ps axf >> or just man ps > > Ok. I have checked this. Almost all of the TUX processes are in S > state. > > But still my load average is about 2. What does this mean? This machine > is dedicated to TUX server btw. The traffic is pretty huge, about 4 > million pageview / day. 1 page has about 10 images, so it is about 40 > million access to the images. ps ax | grep -w '[DRZ]' that will show you all processes running, in D state (waiting for I/O) and zombies perhaps that'll help you out From bkesuma at ml.gaijinweb.com Fri Sep 3 10:28:21 2004 From: bkesuma at ml.gaijinweb.com (Batara Kesuma) Date: Fri, 3 Sep 2004 19:28:21 +0900 Subject: Maximum performance for caching In-Reply-To: <024D6108-FD82-11D8-B1AC-000D936B7E6A@karlsbakk.net> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> <024D6108-FD82-11D8-B1AC-000D936B7E6A@karlsbakk.net> Message-ID: <20040903192821.775995dc.bkesuma@ml.gaijinweb.com> Hi Roy, > ps ax | grep -w '[DRZ]' > that will show you all processes running, in D state (waiting for I/O) > > and zombies > > perhaps that'll help you out I tried this, and on a random time, I have an average of 3 D state. Is this normal? From williama_lovaton at coomeva.com.co Fri Sep 3 22:45:05 2004 From: williama_lovaton at coomeva.com.co (William Lovaton) Date: 03 Sep 2004 17:45:05 -0500 Subject: Maximum performance for caching In-Reply-To: <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> Message-ID: <1094251504.2322.176.camel@localhost.localdomain> Hi Batara, El vie, 03-09-2004 a las 02:32, Batara Kesuma escribi?: > But still my load average is about 2. What does this mean? This machine > is dedicated to TUX server btw. The traffic is pretty huge, about 4 > million pageview / day. 1 page has about 10 images, so it is about 40 > million access to the images. Huge traffic BTW. A load average of 2 means that there are 2 processes waiting to be executed in the OS. Meaning that if you have an SMP box with 2 proccessors, every thing is pretty much Ok. In Uniprocessors systems means that one is executing and the other one is waiting for the CPU. What kind of hardware do you use? (proccessors, RAM, SCSI|IDE). What kernel are you running? I have a PHP web app running with apache alone in an old 4X SMP box 700MHz, 2GB in RAM. The load average usually gets between 20 and 40 an even with that time responses are good. The highest peak value I have ever seen is 82. The server gets about 4 millions of hits per day and in high traffic hours it reachs 120 hits per second avg. The highest being 280. Looking at the statistics in the apache access_log, almost 70% of the requests are static content, so tux would be a fantastic thing here. TUX is really brilliant with static content. -William From roy at karlsbakk.net Sat Sep 4 09:27:05 2004 From: roy at karlsbakk.net (Roy Sigurd Karlsbakk) Date: Sat, 4 Sep 2004 11:27:05 +0200 Subject: Maximum performance for caching In-Reply-To: <20040903192821.775995dc.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> <024D6108-FD82-11D8-B1AC-000D936B7E6A@karlsbakk.net> <20040903192821.775995dc.bkesuma@ml.gaijinweb.com> Message-ID: <95CDD1B4-FE54-11D8-B7F2-000393950CC2@karlsbakk.net> >> ps ax | grep -w '[DRZ]' >> that will show you all processes running, in D state (waiting for I/O) >> >> and zombies >> >> perhaps that'll help you out > > I tried this, and on a random time, I have an average of 3 D state. Is > this normal? not really a process in D state is waiting for I/O. If you have a high number of D state processes, this usually means some drive is fscked or an NFS server you're using has gone out for lunch roy From bkesuma at ml.gaijinweb.com Mon Sep 6 01:42:56 2004 From: bkesuma at ml.gaijinweb.com (Batara Kesuma) Date: Mon, 6 Sep 2004 10:42:56 +0900 Subject: Maximum performance for caching In-Reply-To: <1094251504.2322.176.camel@localhost.localdomain> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> <1094251504.2322.176.camel@localhost.localdomain> Message-ID: <20040906104256.1d79621f.bkesuma@ml.gaijinweb.com> Hi William, > What kind of hardware do you use? (proccessors, RAM, SCSI|IDE). What > kernel are you running? My TUX servers are running: tux-3.2.18-1 kernel-smp-2.6.5-1.358 The hardware is: Pentium 4 2.80GHz (with HT) 1GB RAM 80GB HDD SATA But mostly of the images are served from NFS. The NFS server has the same specs, except it has 250GB HDD SATA with RAID 1. I think the bottleneck is on the NFS server. > Looking at the statistics in the apache access_log, almost 70% of the > requests are static content, so tux would be a fantastic thing here. > TUX is really brilliant with static content. Yes, more than 80% of the requests are static contents. TUX is amazing, but the problem is the NFS server :( From sitz at onastick.net Mon Sep 6 17:06:13 2004 From: sitz at onastick.net (Noah) Date: Mon, 6 Sep 2004 13:06:13 -0400 Subject: Maximum performance for caching In-Reply-To: <20040906104256.1d79621f.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> <1094251504.2322.176.camel@localhost.localdomain> <20040906104256.1d79621f.bkesuma@ml.gaijinweb.com> Message-ID: <20040906170613.GC28371@radu.onastick.net> On Mon, Sep 06, 2004 at 10:42:56AM +0900, Batara Kesuma wrote: > Yes, more than 80% of the requests are static contents. TUX is amazing, > but the problem is the NFS server :( May be able to tune the NFS server a bit to improve performance. IF the NFS server is in the same physicaly building as the front-end machines, you likely don't need TCP-based NFS; switch to UDP. I ran NFS-based webservers for a couple of years, and the performance benefit from using UDP is significant. You can also increase the size of the NFS buffer size. Ultimately, however, NFS is rarely as fast a local disk (a possible exception to this is using a NetApp NFS server; NetApp swears up and down that their RAID4/WAFL systems are on-par with local disk for access times; it's what I ran when I was using NFS for my webservers). If you need a central disk array, you could look into a SAN solution (EMC, etc) if you have the money. Most people don't. =) Another possibility is that cachefs patches were recently produced (see: http://lwn.net/Articles/99597/) which *could* improve your NFS situation. Note that I stress *could*; that code has *not* been merged into the kernel tree, and likely still has a few lingering bugs. Additionally, I've not used it, so can't advise as to what gotchas may be lurking around the corner. YMMV. =) --n -- We need to fold the monkey. From shinerchan at yahoo.com.cn Mon Sep 6 15:48:32 2004 From: shinerchan at yahoo.com.cn (=?gb2312?q?shiner=20chan?=) Date: Mon, 6 Sep 2004 23:48:32 +0800 (CST) Subject: question Message-ID: <20040906154832.5206.qmail@web15706.mail.cnb.yahoo.com> my question is which listens the requestion from web browser if TUX build in kernel ?I consider the kernel should do it ! yes or no? if TUX is placed in kernel ,how does it work ? the work flow is ? and which data structure does refer to in kernel ? thanks!! shiner chan 09/06/2004 --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredan-tux at fredan.org Mon Sep 6 20:49:48 2004 From: fredan-tux at fredan.org (fredrik danerklint) Date: Mon, 6 Sep 2004 22:49:48 +0200 Subject: Tux for 2.6.7 (or 2.6.8) In-Reply-To: <20040801180639.GA10572@elte.hu> References: <1091027000.23836.42.camel@mcdlp.pbi.daviesinc.com> <20040801180639.GA10572@elte.hu> Message-ID: <200409062249.48815.fredan-tux@fredan.org> Ingo, > > I notice on > > > > http://people.redhat.com/mingo/TUX-patches/ > > > > the latest 2.6 kernel supported is 2.6.5 > > > > I tried applying the patches to 2.6.7, but they don't apply cleanly. > > When 2.6.8 is released, will there be an updated patch file made > > available? > > the most recent port of Tux is in Arjan's kernel rpms (which are also > the rpms used for Fedora 2 and 3): > > http://redhat.com/~arjanv/2.6/ > > the Tux patch in the SRPM should apply to vanilla kernels too. The patch which is inside the file http://people.redhat.com/arjanv/2.6/SRPMS.kernel/kernel-2.6.8-1.533.src.rpm (linux-2.6.2-tux.patch) does work on a vanilla 2.6.8.1 kernel. However, there are four missing symbols, which need to be fixed. Output from dmesg: tux: Unknown symbol chroot tux: Unknown symbol write tux: Unknown symbol chdir tux: Unknown symbol read net/tux/main.c: In function `tux_chroot': net/tux/main.c:196: warning: implicit declaration of function `chroot' net/tux/main.c:198: warning: implicit declaration of function `chdir' net/tux/extcgi.c: In function `handle_cgi_reply': net/tux/extcgi.c:90: warning: implicit declaration of function `read' net/tux/extcgi.c: In function `exec_external_cgi': net/tux/extcgi.c:278: warning: implicit declaration of function `write' -- //fredan From mingo at elte.hu Thu Sep 9 17:06:18 2004 From: mingo at elte.hu (Ingo Molnar) Date: Thu, 9 Sep 2004 19:06:18 +0200 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <20040419070756.GA15513@elte.hu> References: <20040419070756.GA15513@elte.hu> Message-ID: <20040909170618.GA27795@elte.hu> the latest Tux patch merged to 2.6.8.1 is available at: redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A3 this fixes the symbol export problem reported by Fredrik Danerklint, and cleans up cpumask handling. The log_cpu_mask tunable moved from /proc/sys/net/tux/ to /proc/net/tux/. Ingo From mingo at elte.hu Thu Sep 9 16:59:32 2004 From: mingo at elte.hu (Ingo Molnar) Date: Thu, 9 Sep 2004 18:59:32 +0200 Subject: Tux for 2.6.7 (or 2.6.8) In-Reply-To: <200409062249.48815.fredan-tux@fredan.org> References: <1091027000.23836.42.camel@mcdlp.pbi.daviesinc.com> <20040801180639.GA10572@elte.hu> <200409062249.48815.fredan-tux@fredan.org> Message-ID: <20040909165932.GA23815@elte.hu> * fredrik danerklint wrote: > > the most recent port of Tux is in Arjan's kernel rpms (which are also > > the rpms used for Fedora 2 and 3): > > > > http://redhat.com/~arjanv/2.6/ > > > > the Tux patch in the SRPM should apply to vanilla kernels too. > > The patch which is inside the file > http://people.redhat.com/arjanv/2.6/SRPMS.kernel/kernel-2.6.8-1.533.src.rpm > (linux-2.6.2-tux.patch) does work on a vanilla 2.6.8.1 kernel. However, there > are four missing symbols, which need to be fixed. > > Output from dmesg: > tux: Unknown symbol chroot > tux: Unknown symbol write > tux: Unknown symbol chdir > tux: Unknown symbol read indeed. The way to do syscalls from within the kernel has changed yet again. Does the attached patch help? (the patch also cleans up the cpumask parsing code. This resulted in the log_cpu_mask tunable moving from /proc/sys/net/tux/ to /proc/net/tux/.) Ingo -------------- next part -------------- --- linux/include/net/tux.h.orig +++ linux/include/net/tux.h @@ -37,6 +37,8 @@ #include #include #include +#include +#include #include #include @@ -709,13 +711,13 @@ extern void send_abuf (tux_req_t *req, u extern int idle_event (tux_req_t *req); extern int output_space_event (tux_req_t *req); -extern unsigned int log_cpu_mask; +extern cpumask_t tux_log_cpu_mask; extern unsigned int tux_compression; extern unsigned int tux_noid; extern unsigned int tux_cgi_inherit_cpu; extern unsigned int tux_zerocopy_header; extern unsigned int tux_zerocopy_sendfile; -extern unsigned int tux_cgi_cpu_mask; +extern cpumask_t tux_cgi_cpu_mask; extern tux_proto_t tux_proto_http; extern tux_proto_t tux_proto_ftp; extern unsigned int tux_all_userspace; --- linux/fs/open.c.orig +++ linux/fs/open.c @@ -536,6 +536,8 @@ out: return error; } +EXPORT_SYMBOL(sys_chdir); + asmlinkage long sys_fchdir(unsigned int fd) { struct file *file; @@ -592,6 +594,8 @@ out: return error; } +EXPORT_SYMBOL(sys_chroot); + asmlinkage long sys_fchmod(unsigned int fd, mode_t mode) { struct inode * inode; --- linux/fs/read_write.c.orig +++ linux/fs/read_write.c @@ -315,6 +315,8 @@ asmlinkage ssize_t sys_write(unsigned in return ret; } +EXPORT_SYMBOL(sys_write); + asmlinkage ssize_t sys_pread64(unsigned int fd, char __user *buf, size_t count, loff_t pos) { --- linux/net/tux/main.c.orig +++ linux/net/tux/main.c @@ -192,9 +192,9 @@ int tux_chroot (char *dir) set_fs(KERNEL_DS); cap_raise (current->cap_effective, CAP_SYS_CHROOT); - err = chroot(dir); + err = sys_chroot(dir); if (!err) - chdir("/"); + sys_chdir("/"); current->cap_effective = saved_cap; set_fs(oldmm); @@ -446,14 +446,14 @@ static int user_req_start_thread (thread cpu = ti->cpu; #if CONFIG_SMP { - unsigned int mask; - cpumask_t cpu_mask, map; + unsigned int home_cpu; + cpumask_t map; - mask = 1 << ((cpu + tux_cpu_offset) % num_online_cpus()); + home_cpu = (cpu + tux_cpu_offset) % num_online_cpus(); + map = cpumask_of_cpu(home_cpu); - mask_to_cpumask(mask, &cpu_mask); - cpus_and(map, cpu_mask, cpu_online_map); - if(!(cpus_empty(map))) + cpus_and(map, map, cpu_online_map); + if (!(cpus_empty(map))) set_cpus_allowed(current, map); } #endif --- linux/net/tux/extcgi.c.orig +++ linux/net/tux/extcgi.c @@ -87,7 +87,7 @@ repeat: repeat_read: Dprintk("reading %d bytes via read().\n", left); oldmm = get_fs(); set_fs(KERNEL_DS); - len = read(2, tmp, left); + len = sys_read(2, tmp, left); set_fs(oldmm); Dprintk("got %d bytes from read() (total: %d).\n", len, total); if (len > 0) @@ -275,7 +275,7 @@ static int exec_external_cgi (void *data Dprintk("POST data to CGI:\n"); oldmm = get_fs(); set_fs(KERNEL_DS); - ret = write(1, req->post_data_str, req->post_data_len); + ret = sys_write(1, req->post_data_str, req->post_data_len); set_fs(oldmm); Dprintk("write() returned: %d.\n", ret); if (ret != req->post_data_len) --- linux/net/tux/proc.c.orig +++ linux/net/tux/proc.c @@ -53,11 +53,11 @@ unsigned int tux_ftp_virtual_server = 0; unsigned int mass_hosting_hash = 0; unsigned int strip_host_tail = 0; unsigned int tux_max_object_size = 0; -unsigned int log_cpu_mask = ~0; +cpumask_t tux_log_cpu_mask = CPU_MASK_ALL; unsigned int tux_compression = 0; unsigned int tux_noid = 0; unsigned int tux_cgi_inherit_cpu = 0; -unsigned int tux_cgi_cpu_mask = ~0; +cpumask_t tux_cgi_cpu_mask = CPU_MASK_ALL; unsigned int tux_zerocopy_header = 1; unsigned int tux_max_free_requests = 1000; unsigned int tux_ignore_query = 0; @@ -622,18 +622,6 @@ static ctl_table tux_table[] = { NULL, NULL }, - { NET_TUX_CGI_CPU_MASK, - "cgi_cpu_mask", - &tux_cgi_cpu_mask, - sizeof(int), - 0644, - NULL, - proc_dointvec, - &sysctl_intvec, - NULL, - NULL, - NULL - }, { NET_TUX_ZEROCOPY_HEADER, "zerocopy_header", &tux_zerocopy_header, @@ -770,6 +758,7 @@ static ctl_table tux_root_table[] = { static struct proc_dir_entry * root_tux_dir; static struct proc_dir_entry * log_cpu_mask_entry; +static struct proc_dir_entry * cgi_cpu_mask_entry; static struct proc_dir_entry * stat_entry; static struct proc_dir_entry * tux_dir [CONFIG_TUX_NUMTHREADS]; static struct proc_dir_entry * listen_dir [CONFIG_TUX_NUMTHREADS]; @@ -777,51 +766,29 @@ static struct proc_dir_entry * listen_di tux_socket_t tux_listen [CONFIG_TUX_NUMTHREADS][CONFIG_TUX_NUMSOCKETS] = { [0 ... CONFIG_TUX_NUMTHREADS-1] = { {&tux_proto_http, 0, 80, NULL}, } }; -#define HEX_DIGITS 8 - -static int hex_read_proc (char *page, char **start, off_t off, - int count, int *eof, void *data) +static int cpu_mask_read_proc (char *page, char **start, off_t off, + int count, int *eof, void *data) { - if (count < HEX_DIGITS+1) + int len = cpumask_scnprintf(page, count, *(cpumask_t *)data); + if (count - len < 2) return -EINVAL; - return sprintf (page, "%08x\n", *(unsigned int *)data); + len += sprintf(page + len, "\n"); + return len; } -static int hex_write_proc (struct file *file, const char *buffer, +static int cpu_mask_write_proc (struct file *file, + const char __user *buffer, unsigned long count, void *data) { - char hexnum [HEX_DIGITS]; - unsigned int new_value; - unsigned int i, full_count = count; - - if (!count) - return -EINVAL; - if (count > HEX_DIGITS) - count = HEX_DIGITS; - if (copy_from_user(hexnum, buffer, count)) - return -EFAULT; - - /* - * Parse the first 8 characters as a hex string, any non-hex char - * is end-of-string. '00e1', 'e1', '00E1', 'E1' are the same. - */ - new_value = 0; - - for (i = 0; i < count; i++) { - unsigned int c = hexnum[i]; - - switch (c) { - case '0' ... '9': c -= '0'; break; - case 'a' ... 'f': c -= 'a'-10; break; - case 'A' ... 'F': c -= 'A'-10; break; - default: - goto out; - } - new_value = (new_value << 4) | c; - } -out: - *(int *)data = new_value; + cpumask_t *mask = (cpumask_t *)data; + unsigned long full_count = count, err; + cpumask_t new_value; + + err = cpumask_parse(buffer, count, new_value); + if (err) + return err; + *mask = new_value; return full_count; } @@ -1118,6 +1085,7 @@ static void cleanup_tux_proc (void) unregister_tux_proc(i); remove_proc_entry(stat_entry->name, root_tux_dir); remove_proc_entry(log_cpu_mask_entry->name, root_tux_dir); + remove_proc_entry(cgi_cpu_mask_entry->name, root_tux_dir); remove_proc_entry(root_tux_dir->name, proc_net); } @@ -1135,12 +1103,21 @@ static void init_tux_proc (void) entry = create_proc_entry("log_cpu_mask", 0700, root_tux_dir); entry->nlink = 1; - entry->data = (void *)&log_cpu_mask; - entry->read_proc = hex_read_proc; - entry->write_proc = hex_write_proc; + entry->data = (void *)&tux_log_cpu_mask; + entry->read_proc = cpu_mask_read_proc; + entry->write_proc = cpu_mask_write_proc; log_cpu_mask_entry = entry; + entry = create_proc_entry("cgi_cpu_mask", 0700, root_tux_dir); + + entry->nlink = 1; + entry->data = (void *)&tux_cgi_cpu_mask; + entry->read_proc = cpu_mask_read_proc; + entry->write_proc = cpu_mask_write_proc; + + cgi_cpu_mask_entry = entry; + entry = create_proc_entry("stat", 0700, root_tux_dir); entry->nlink = 1; @@ -1169,22 +1146,4 @@ void end_sysctl(void) unregister_sysctl_table(tux_table_header); } -#if CONFIG_SMP -void mask_to_cpumask(unsigned int mask, cpumask_t *cpu_mask) -{ - - unsigned int bit_mask, i; - - bit_mask = 1 << 31; - - for (i=NR_CPUS-1; i--; i >= 0) { - if(mask & bit_mask) - cpu_set(i, *cpu_mask); - else - cpu_clear(i, *cpu_mask); - mask <<= 1; - } - -} -#endif --- linux/net/tux/cgi.c.orig +++ linux/net/tux/cgi.c @@ -75,14 +75,12 @@ static int exec_helper (void * data) sprintf(current->comm,"doexec - %d", current->pid); #if CONFIG_SMP if (!tux_cgi_inherit_cpu) { + cpumask_t map; - cpumask_t cgi_mask, map; - - mask_to_cpumask(tux_cgi_cpu_mask, &cgi_mask); - cpus_and(map, cpu_online_map, cgi_mask); + cpus_and(map, cpu_online_map, tux_cgi_cpu_mask); if (!(cpus_empty(map))) - set_cpus_allowed(current, cgi_mask); + set_cpus_allowed(current, map); else set_cpus_allowed(current, cpu_online_map); } --- linux/net/tux/logger.c.orig +++ linux/net/tux/logger.c @@ -766,11 +766,10 @@ static int logger_thread (void *data) printk(KERN_NOTICE "TUX: logger thread started.\n"); #if CONFIG_SMP { - cpumask_t log_mask, map; + cpumask_t map; - mask_to_cpumask(log_cpu_mask, &log_mask); - cpus_and(map, cpu_online_map, log_mask); - if(!(cpus_empty(map))) + cpus_and(map, cpu_online_map, tux_log_cpu_mask); + if (!(cpus_empty(map))) set_cpus_allowed(current, map); } From mingo at elte.hu Thu Sep 9 18:54:37 2004 From: mingo at elte.hu (Ingo Molnar) Date: Thu, 9 Sep 2004 20:54:37 +0200 Subject: Maximum performance for caching In-Reply-To: <20040906104256.1d79621f.bkesuma@ml.gaijinweb.com> References: <20040903120532.22c4cb9e.bkesuma@ml.gaijinweb.com> <1094180982.16664.17.camel@mcdlp.pbi.daviesinc.com> <20040903151709.564803be.bkesuma@ml.gaijinweb.com> <20040903163207.3a7e2950.bkesuma@ml.gaijinweb.com> <1094251504.2322.176.camel@localhost.localdomain> <20040906104256.1d79621f.bkesuma@ml.gaijinweb.com> Message-ID: <20040909185437.GA32045@elte.hu> * Batara Kesuma wrote: > Hi William, > > > What kind of hardware do you use? (proccessors, RAM, SCSI|IDE). What > > kernel are you running? > > My TUX servers are running: > tux-3.2.18-1 > kernel-smp-2.6.5-1.358 > > The hardware is: > Pentium 4 2.80GHz (with HT) > 1GB RAM > 80GB HDD SATA > > But mostly of the images are served from NFS. The NFS server has the > same specs, except it has 250GB HDD SATA with RAID 1. I think the > bottleneck is on the NFS server. what is the typical 'hot content' size (that users are accessing) - much larger than 1 GB? > > Looking at the statistics in the apache access_log, almost 70% of the > > requests are static content, so tux would be a fantastic thing here. > > TUX is really brilliant with static content. > > Yes, more than 80% of the requests are static contents. TUX is > amazing, but the problem is the NFS server :( you can increase IO parallelism by increasing NR_IO_THREADS from 32 to 64 (or higher) in include/net/tux.h. (Note that this will add a whole bunch of IO threads but with a high-latency NFS server those are needed if your working set is much larger than the 1GB of RAM.) could you run 'top', enter 'h' and 's60' (show all threads and 60 second measurement interval) and copy & paste the full screen (once the first 1 minute measurement has been displayed) and send it to me? 'D' state processes and a high load are not necessarily an issue unless the response times of your server are bad and still you have alot of idle CPU time and idle network bandwidth. Ingo From shinerchan at yahoo.com.cn Fri Sep 10 12:39:31 2004 From: shinerchan at yahoo.com.cn (=?gb2312?q?shiner=20chan?=) Date: Fri, 10 Sep 2004 20:39:31 +0800 (CST) Subject: documents the architecture of Tux from a higher level Message-ID: <20040910123931.64571.qmail@web15702.mail.cnb.yahoo.com> Now I want replant the Tux to FreeBsd ,but I meet much trobule . In debugging that problem, I've been reading docs and source code and using various debugging tools. However, I'm hindered by the fact that I don't have a big picture perspective of the Tux architecture. Is there any place that documents the architecture of Tux from a higher level? That explains some of the data structures and how they relate to each other? That explains the various threads that are executing and how they're scheduled? If such docs don't exist and someone could answer some questions, I'll try to work up something like that. Thanks, shinerchan --------------------------------- Do You Yahoo!? 150??MP3???????????? ??????????????????? 1G??1000??????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sapan.bhatia at inria.fr Fri Sep 10 14:23:41 2004 From: sapan.bhatia at inria.fr (Sapan Bhatia) Date: Fri, 10 Sep 2004 16:23:41 +0200 Subject: documents the architecture of Tux from a higher level In-Reply-To: <20040910123931.64571.qmail@web15702.mail.cnb.yahoo.com> References: <20040910123931.64571.qmail@web15702.mail.cnb.yahoo.com> Message-ID: <20040910142341.GA9227@inria.fr> hi, here's one: http://www.citi.umich.edu/techreports/reports/citi-tr-00-8.pdf. there's also a high level overview of TUX in a paper titled "Accept()able strategies" in the USENIX annual tech. conf, 2004 (available via google). -sapan On Fri, Sep 10, 2004 at 08:39:31PM +0800, shiner chan wrote: > opera: spellcheck.so: cannot open shared object file: No such file or directory > opera: Could not initialize spell checker interface. Generic failure (-1) > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list From anton at samba.org Fri Sep 10 16:20:28 2004 From: anton at samba.org (Anton Blanchard) Date: Sat, 11 Sep 2004 02:20:28 +1000 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <20040909170618.GA27795@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> Message-ID: <20040910162028.GQ24408@krispykreme> Hi Ingo, > the latest Tux patch merged to 2.6.8.1 is available at: > > redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A3 > > this fixes the symbol export problem reported by Fredrik Danerklint, and > cleans up cpumask handling. The log_cpu_mask tunable moved from > /proc/sys/net/tux/ to /proc/net/tux/. Here is Andrew Mortons patch from a while ago to do more intelligent writeout/invalidation of the logfile. It made writeout much more smooth. Also I couldnt compile tux when it wasnt a module. Moving tux_module outside CONFIG_MODULE fixed that. (FYI open_private_file disappeared in current BK.) Anton -------------- next part -------------- diff -puN include/linux/fs.h~tux-better-logwrite include/linux/fs.h --- foobar2/include/linux/fs.h~tux-better-logwrite 2004-09-11 02:07:16.982705700 +1000 +++ foobar2-anton/include/linux/fs.h 2004-09-11 02:07:17.015703164 +1000 @@ -588,6 +588,9 @@ struct file { struct list_head f_ep_links; spinlock_t f_ep_lock; #endif /* #ifdef CONFIG_EPOLL */ +#ifdef CONFIG_TUX + loff_t f_last_index; +#endif struct address_space *f_mapping; }; extern spinlock_t files_lock; diff -puN net/tux/logger.c~tux-better-logwrite net/tux/logger.c --- foobar2/net/tux/logger.c~tux-better-logwrite 2004-09-11 02:07:16.989705162 +1000 +++ foobar2-anton/net/tux/logger.c 2004-09-11 02:07:17.018702933 +1000 @@ -681,6 +681,8 @@ static unsigned int writeout_log (void) struct file *log_filp; char * str; unsigned int ret; + struct inode *inode; + struct address_space *mapping; if (tux_logging) Dprintk("TUX logger: opening log file {%s}.\n", tux_logfile); @@ -725,18 +727,22 @@ static unsigned int writeout_log (void) /* * Sync log data to disk: */ - if (log_filp->f_op && log_filp->f_op->fsync) { - down(&log_filp->f_dentry->d_inode->i_sem); - log_filp->f_op->fsync(log_filp, log_filp->f_dentry, 1); - up(&log_filp->f_dentry->d_inode->i_sem); + inode = log_filp->f_dentry->d_inode; + mapping = inode->i_mapping; + if (mapping->nrpages > 256) { /* batch stuff up */ + down(&inode->i_sem); + filemap_fdatawrite(inode->i_mapping); + + /* + * Now nuke old pagecache up to the place where we just + * started the I/O. There's no point in trying to invalidate + * pages after that, because they're currently in-flight. + */ + invalidate_mapping_pages(mapping, 0, log_filp->f_last_index); + log_filp->f_last_index = log_filp->f_pos >> PAGE_CACHE_SHIFT; + up(&inode->i_sem); } - /* - * Reduce the cache footprint of the logger file - it's - * typically write-once. - */ - invalidate_inode_pages(log_filp->f_dentry->d_inode->i_mapping); - out_lock: spin_lock(&log_lock); out: _ -------------- next part -------------- diff -puN net/socket.c~fix_tuxmodule net/socket.c --- foobar2/net/socket.c~fix_tuxmodule 2004-09-11 02:01:56.135071423 +1000 +++ foobar2-anton/net/socket.c 2004-09-11 02:02:04.815730266 +1000 @@ -2086,11 +2086,12 @@ void __init sock_init(void) int tux_Dprintk; int tux_TDprintk; +struct module *tux_module = NULL; + #ifdef CONFIG_TUX_MODULE asmlinkage long (*sys_tux_ptr) (unsigned int action, user_req_t *u_info) = NULL; -struct module *tux_module = NULL; spinlock_t tux_module_lock = SPIN_LOCK_UNLOCKED; asmlinkage long sys_tux (unsigned int action, user_req_t *u_info) _ From mingo at elte.hu Fri Sep 10 19:36:30 2004 From: mingo at elte.hu (Ingo Molnar) Date: Fri, 10 Sep 2004 21:36:30 +0200 Subject: [patch] tux3-2.6.8.1-A4 In-Reply-To: <20040910162028.GQ24408@krispykreme> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <20040910162028.GQ24408@krispykreme> Message-ID: <20040910193630.GB19488@elte.hu> * Anton Blanchard wrote: > Here is Andrew Mortons patch from a while ago to do more intelligent > writeout/invalidation of the logfile. It made writeout much more > smooth. > > Also I couldnt compile tux when it wasnt a module. Moving tux_module > outside CONFIG_MODULE fixed that. thanks - i've put these into -A4: http://redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A3 Ingo From mingo at elte.hu Fri Sep 10 14:15:11 2004 From: mingo at elte.hu (Ingo Molnar) Date: Fri, 10 Sep 2004 16:15:11 +0200 Subject: documents the architecture of Tux from a higher level In-Reply-To: <20040910123931.64571.qmail@web15702.mail.cnb.yahoo.com> References: <20040910123931.64571.qmail@web15702.mail.cnb.yahoo.com> Message-ID: <20040910141511.GA10713@elte.hu> * shiner chan wrote: > Now I want replant the Tux to FreeBsd [...] as a sidenote, you know that Tux is GPL-ed code, right? So combining the FreeBSD and Tux code may not be possible due to the advertising clause. Other, GPL-compatible BSD licenses are probably fine. Ingo From fredan-tux at fredan.org Fri Sep 10 20:14:02 2004 From: fredan-tux at fredan.org (fredrik danerklint) Date: Fri, 10 Sep 2004 22:14:02 +0200 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <20040909170618.GA27795@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> Message-ID: <200409102214.02264.fredan-tux@fredan.org> Ingo, > the latest Tux patch merged to 2.6.8.1 is available at: > > redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A3 > > this fixes the symbol export problem reported by Fredrik Danerklint, and Thanks for fixing this. I had to make an new bzImage and boot that before I got it to work.... However, I have another problem now with tux. Can it handle files which is an link? Everytime I access an link, tux crashes. Both the http and ftp server. This is what I've got from dmesg: ------------[ cut here ]------------ kernel BUG at fs/namei.c:481! invalid operand: 0000 [#7] Modules linked in: tux zlib_deflate md5 ipv6 rtc 3c59x ide_cd cdrom CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010296 (2.6.8.1) EIP is at link_path_walk+0x831/0xcf0 eax: dd5abe9c ebx: dd5ab000 ecx: d8f3f0b0 edx: d8f430cc esi: dd5abe58 edi: dd5abe5c ebp: ffffffd8 esp: dd5abe38 ds: 007b es: 007b ss: 0068 Process async IO 0/7 (pid: 5358, threadinfo=dd5ab000 task=dd5c8740) Stack: d8f3f0b0 00000000 00000000 00000000 00000003 00000000 d8f430cc dd5abe9c dffb7920 d8f3f0b0 1200a422 df19ba38 00000005 dffb7f80 dd5abe9c 00000000 00000001 df590ba0 e08ca330 df19b800 e08ca43d df19b800 df19ba38 dd5abe9c Call Trace: [] __tux_lookup+0x10/0x30 [tux] [] tux_lookup+0xad/0xf0 [tux] [] activate_task+0x51/0x70 [] try_to_wake_up+0x3c/0x90 [] lookup_url+0x6e/0x5f0 [tux] [] wake_up_process+0xd/0x10 [] add_req_to_workqueue+0xe/0x20 [tux] [] http_lookup_vhost+0xda/0x120 [tux] [] schedule+0x93/0x460 [] http_process_message+0x48/0x2b0 [tux] [] tux_schedule_atom+0x29/0x50 [tux] [] cachemiss_thread+0x139/0x1b0 [tux] [] default_wake_function+0x0/0x20 [] default_wake_function+0x0/0x20 [] cachemiss_thread+0x0/0x1b0 [tux] [] kernel_thread_helper+0x5/0x10 Code: 0f 0b e1 01 fa 0b 26 c0 8b 43 08 a8 08 74 05 e8 8b 5b 10 00 This is when I access an directory which has no index file, so apache should have had this request instead. The directory look like this: trollet downloads # ls -l total 12 drwxrwxr-x 2 root root 4096 Sep 5 23:22 5.1.1 drwxrwxr-x 2 root root 4096 Sep 6 09:08 6.0-testing-20040905 drwxrwxr-x 2 root root 4096 Sep 6 09:21 SVN-20040904 lrwxrwxrwx 1 root root 5 Sep 6 18:37 stable -> 5.1.1 lrwxrwxrwx 1 root root 20 Sep 6 18:37 testing -> 6.0-testing-20040905 lrwxrwxrwx 1 root root 12 Sep 6 18:37 unstable -> SVN-20040904 ------------[ cut here ]------------ kernel BUG at fs/namei.c:481! invalid operand: 0000 [#8] Modules linked in: tux zlib_deflate md5 ipv6 rtc 3c59x ide_cd cdrom CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010296 (2.6.8.1) EIP is at link_path_walk+0x831/0xcf0 eax: dd5adf10 ebx: dd5ad000 ecx: d8f3f0b0 edx: d8f430cc esi: dd5adecc edi: dd5aded0 ebp: ffffffd8 esp: dd5adeac ds: 007b es: 007b ss: 0068 Process async IO 0/8 (pid: 5359, threadinfo=dd5ad000 task=dd5c81b0) Stack: d8f3f0b0 c010f3f1 dd5b7240 dd5adedc 00000001 00000000 d8f430cc dd5adf10 dffb7920 d8f3f0b0 1200a422 decca238 00000005 dd5adefc dd5adf10 decca000 df590ba4 df590ba0 e08ca330 decca000 e08ca43d decca000 decca238 dd5adf10 Call Trace: [] recalc_task_prio+0x161/0x200 [] __tux_lookup+0x10/0x30 [tux] [] tux_lookup+0xad/0xf0 [tux] [] schedule+0x93/0x460 [] ftp_chdir+0x29/0x110 [tux] [] tux_schedule_atom+0x29/0x50 [tux] [] cachemiss_thread+0x139/0x1b0 [tux] [] default_wake_function+0x0/0x20 [] default_wake_function+0x0/0x20 [] cachemiss_thread+0x0/0x1b0 [tux] [] kernel_thread_helper+0x5/0x10 Code: 0f 0b e1 01 fa 0b 26 c0 8b 43 08 a8 08 74 05 e8 8b 5b 10 00 This is from the ftp-server. What I did on the client was to change to a directory, which is an link to a another directory. trollet ftp.fredan.org # ls -l total 8 drwxr-xr-x 5 root root 4096 Sep 5 23:09 gentoo lrwxr-xr-x 1 root root 3 Sep 9 23:01 kalle -> pub drwxr-xr-x 4 root root 4096 Sep 5 22:38 pub It is the directory called "kalle" in this case... The output from ps: 5348 ? S 0:00 [TUX date] 5349 ? SW 0:00 [TUX logger] 5350 ? S 0:00 [TUX manager] 5351 ? S 0:00 \_ [TUX worker 0] 5352 ? Z 0:00 \_ [async IO 0/1] 5353 ? Z 0:00 \_ [async IO 0/2] 5354 ? Z 0:00 \_ [async IO 0/3] 5355 ? Z 0:00 \_ [async IO 0/4] 5356 ? Z 0:00 \_ [async IO 0/5] 5357 ? Z 0:00 \_ [async IO 0/6] 5358 ? Z 0:00 \_ [async IO 0/7] 5359 ? Z 0:00 \_ [async IO 0/8] 5360 ? S 0:00 \_ [TUX worker 0] -- //fredan From mark.van.leeuwen at virgil.nl Sun Sep 12 07:14:55 2004 From: mark.van.leeuwen at virgil.nl (Mark van Leeuwen) Date: Sun, 12 Sep 2004 09:14:55 +0200 Subject: [patch] tux3-2.6.8.1-A4 In-Reply-To: <20040910193630.GB19488@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <20040910162028.GQ24408@krispykreme> <20040910193630.GB19488@elte.hu> Message-ID: <4143F76F.1030400@virgil.nl> Ingo Molnar wrote: >thanks - i've put these into -A4: > > http://redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A3 > > I guess you meant http://redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A4 ;-) -- Mark From mingo at elte.hu Sun Sep 12 10:00:10 2004 From: mingo at elte.hu (Ingo Molnar) Date: Sun, 12 Sep 2004 12:00:10 +0200 Subject: [patch] tux3-2.6.8.1-A4 In-Reply-To: <4143F76F.1030400@virgil.nl> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <20040910162028.GQ24408@krispykreme> <20040910193630.GB19488@elte.hu> <4143F76F.1030400@virgil.nl> Message-ID: <20040912100009.GA12351@elte.hu> * Mark van Leeuwen wrote: > I guess you meant > > http://redhat.com/~mingo/TUX-patches/tux3-2.6.8.1-A4 > > ;-) yeah :-| Ingo From williama_lovaton at coomeva.com.co Mon Sep 13 14:17:16 2004 From: williama_lovaton at coomeva.com.co (William Lovaton) Date: 13 Sep 2004 09:17:16 -0500 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <200409102214.02264.fredan-tux@fredan.org> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> Message-ID: <1095085036.10027.20.camel@localhost.localdomain> Ingo, El vie, 10-09-2004 a las 15:14, fredrik danerklint escribi?: > However, I have another problem now with tux. Can it handle files which is an > link? Everytime I access an link, tux crashes. Both the http and ftp server. > This is what I've got from dmesg: Regarding my bug: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125091 I use a link too. I have always used it that way, it worked fine in RedHat 9. May be Frederik's crash is not related but I just wanted to comment that. -William > > ------------[ cut here ]------------ > kernel BUG at fs/namei.c:481! > invalid operand: 0000 [#7] > Modules linked in: tux zlib_deflate md5 ipv6 rtc 3c59x ide_cd cdrom > CPU: 0 > EIP: 0060:[] Not tainted > EFLAGS: 00010296 (2.6.8.1) > EIP is at link_path_walk+0x831/0xcf0 > eax: dd5abe9c ebx: dd5ab000 ecx: d8f3f0b0 edx: d8f430cc > esi: dd5abe58 edi: dd5abe5c ebp: ffffffd8 esp: dd5abe38 > ds: 007b es: 007b ss: 0068 > Process async IO 0/7 (pid: 5358, threadinfo=dd5ab000 task=dd5c8740) > Stack: d8f3f0b0 00000000 00000000 00000000 00000003 00000000 d8f430cc dd5abe9c > dffb7920 d8f3f0b0 1200a422 df19ba38 00000005 dffb7f80 dd5abe9c 00000000 > 00000001 df590ba0 e08ca330 df19b800 e08ca43d df19b800 df19ba38 dd5abe9c > Call Trace: > [] __tux_lookup+0x10/0x30 [tux] > [] tux_lookup+0xad/0xf0 [tux] > [] activate_task+0x51/0x70 > [] try_to_wake_up+0x3c/0x90 > [] lookup_url+0x6e/0x5f0 [tux] > [] wake_up_process+0xd/0x10 > [] add_req_to_workqueue+0xe/0x20 [tux] > [] http_lookup_vhost+0xda/0x120 [tux] > [] schedule+0x93/0x460 > [] http_process_message+0x48/0x2b0 [tux] > [] tux_schedule_atom+0x29/0x50 [tux] > [] cachemiss_thread+0x139/0x1b0 [tux] > [] default_wake_function+0x0/0x20 > [] default_wake_function+0x0/0x20 > [] cachemiss_thread+0x0/0x1b0 [tux] > [] kernel_thread_helper+0x5/0x10 > Code: 0f 0b e1 01 fa 0b 26 c0 8b 43 08 a8 08 74 05 e8 8b 5b 10 00 > > This is when I access an directory which has no index file, so apache should > have had this request instead. > The directory look like this: > > trollet downloads # ls -l > total 12 > drwxrwxr-x 2 root root 4096 Sep 5 23:22 5.1.1 > drwxrwxr-x 2 root root 4096 Sep 6 09:08 6.0-testing-20040905 > drwxrwxr-x 2 root root 4096 Sep 6 09:21 SVN-20040904 > lrwxrwxrwx 1 root root 5 Sep 6 18:37 stable -> 5.1.1 > lrwxrwxrwx 1 root root 20 Sep 6 18:37 testing -> 6.0-testing-20040905 > lrwxrwxrwx 1 root root 12 Sep 6 18:37 unstable -> SVN-20040904 > > > ------------[ cut here ]------------ > kernel BUG at fs/namei.c:481! > invalid operand: 0000 [#8] > Modules linked in: tux zlib_deflate md5 ipv6 rtc 3c59x ide_cd cdrom > CPU: 0 > EIP: 0060:[] Not tainted > EFLAGS: 00010296 (2.6.8.1) > EIP is at link_path_walk+0x831/0xcf0 > eax: dd5adf10 ebx: dd5ad000 ecx: d8f3f0b0 edx: d8f430cc > esi: dd5adecc edi: dd5aded0 ebp: ffffffd8 esp: dd5adeac > ds: 007b es: 007b ss: 0068 > Process async IO 0/8 (pid: 5359, threadinfo=dd5ad000 task=dd5c81b0) > Stack: d8f3f0b0 c010f3f1 dd5b7240 dd5adedc 00000001 00000000 d8f430cc dd5adf10 > dffb7920 d8f3f0b0 1200a422 decca238 00000005 dd5adefc dd5adf10 decca000 > df590ba4 df590ba0 e08ca330 decca000 e08ca43d decca000 decca238 dd5adf10 > Call Trace: > [] recalc_task_prio+0x161/0x200 > [] __tux_lookup+0x10/0x30 [tux] > [] tux_lookup+0xad/0xf0 [tux] > [] schedule+0x93/0x460 > [] ftp_chdir+0x29/0x110 [tux] > [] tux_schedule_atom+0x29/0x50 [tux] > [] cachemiss_thread+0x139/0x1b0 [tux] > [] default_wake_function+0x0/0x20 > [] default_wake_function+0x0/0x20 > [] cachemiss_thread+0x0/0x1b0 [tux] > [] kernel_thread_helper+0x5/0x10 > Code: 0f 0b e1 01 fa 0b 26 c0 8b 43 08 a8 08 74 05 e8 8b 5b 10 00 > > This is from the ftp-server. What I did on the client was to change to a > directory, which is an link to a another directory. > > trollet ftp.fredan.org # ls -l > total 8 > drwxr-xr-x 5 root root 4096 Sep 5 23:09 gentoo > lrwxr-xr-x 1 root root 3 Sep 9 23:01 kalle -> pub > drwxr-xr-x 4 root root 4096 Sep 5 22:38 pub > > It is the directory called "kalle" in this case... > > The output from ps: > 5348 ? S 0:00 [TUX date] > 5349 ? SW 0:00 [TUX logger] > 5350 ? S 0:00 [TUX manager] > 5351 ? S 0:00 \_ [TUX worker 0] > 5352 ? Z 0:00 \_ [async IO 0/1] > 5353 ? Z 0:00 \_ [async IO 0/2] > 5354 ? Z 0:00 \_ [async IO 0/3] > 5355 ? Z 0:00 \_ [async IO 0/4] > 5356 ? Z 0:00 \_ [async IO 0/5] > 5357 ? Z 0:00 \_ [async IO 0/6] > 5358 ? Z 0:00 \_ [async IO 0/7] > 5359 ? Z 0:00 \_ [async IO 0/8] > 5360 ? S 0:00 \_ [TUX worker 0] > From grendel at caudium.net Mon Sep 13 14:36:53 2004 From: grendel at caudium.net (Marek Habersack) Date: Mon, 13 Sep 2004 16:36:53 +0200 Subject: tux-induced kernel BUG() with userspace modules In-Reply-To: <20040818151657.GB5598@beowulf.thanes.org> References: <20040818151657.GB5598@beowulf.thanes.org> Message-ID: <20040913143653.GC4606@beowulf.thanes.org> On Wed, Aug 18, 2004 at 05:16:57PM +0200, Marek Habersack scribbled: Hello again, I'm sorry for being a PITA, but could anybody give me a helping hand with the bug shown below? I will be happy to work on fixing it if I'm given a little bit of guidance as right now I'm completely in the dark about why it is happening, TIA, marek > Hello, > > Working on a userspace module, I came across a problem with > TUX_ACTION_REDIRECT_REQ. Unless I am doing something wrong, the following > module is the simplest possible test case to reproduce the bug: > > #include > > #ifdef TUXAPI_declare > TUXAPI_declare; > #endif > > int TUXAPI_handle_events(user_req_t *req) > { > return tux(TUX_ACTION_REDIRECT_REQ, req); > } > > The environment is: > > 1. tux: tux3 A3 rediffed for 2.4.26 and another for 2.4.26+openwall2, > compiled with debugging stuff, no cgi, extended logging > 2. kernel: as above, 2.4.26 vanilla, 2.4.26-ow2 > 3. machine: P4/1GB RAM, Athlon/1GB RAM, vmware with 256MB ram - I don't > think it matters > 4. tux sysctls used: > net/tux/virtual_server = 0 > net/tux/clientport = 81 > net/tux/referer_logging = 1 > net/tux/referer_blocking = 1 > net/tux/logging = 1 > net/tux/max_keepalives = 1000 > net/tux/keepalive_timeout = 30 > net/tux/TDprintk = 0 > net/tux/Dprintk = 1 > net/tux/generate_cache_control = 1 > net/tux/generate_etags = 1 > net/tux/generate_last_mod = 0 > net/tux/defer_accept = 0 > net/tux/all_userspace = 1 > net/tux/http_subdocroot = docroot > > The oops itself is: > > Aug 18 18:50:59 localhost kernel: kernel BUG at inode.c:1204! > Aug 18 18:50:59 localhost kernel: invalid operand: 0000 > Aug 18 18:50:59 localhost kernel: CPU: 0 > Aug 18 18:50:59 localhost kernel: EIP: 0010:[iput+578/592] Not tainted > Aug 18 18:50:59 localhost kernel: EFLAGS: 00010246 > Aug 18 18:50:59 localhost kernel: eax: c02cf3ec ebx: c5de7480 ecx: 00000000 edx: c5de7490 > Aug 18 18:50:59 localhost kernel: esi: c7e87000 edi: 00000000 ebp: c65e2ec0 esp: c5df3e3c > Aug 18 18:50:59 localhost kernel: ds: 0018 es: 0018 ss: 0018 > Aug 18 18:50:59 localhost kernel: Process tux (pid: 517, stackpage=c5df3000) > Aug 18 18:50:59 localhost kernel: Stack: c5de7480 c5de75a0 c11641c0 c65e2ec0 c5de7480 c5de7480 c01474a0 c5de7480 > Aug 18 18:50:59 localhost kernel: c63ae6c0 c63ae6c0 c11641c0 c01356b6 c65e2ec0 c63ae6c0 c63ae6c0 c6a4ee40 > Aug 18 18:50:59 localhost kernel: 00000000 00000000 c0133dcd c63ae6c0 c6a4ee40 c63ae6c0 00000000 00000000 > Aug 18 18:50:59 localhost kernel: Call Trace: [dput+160/368] [fput+198/288] [filp_close+77/128] [sys_close+78/96] [] > Aug 18 18:50:59 localhost kernel: [] [] [] [] [] [wake_up_process+22/32] > Aug 18 18:50:59 localhost kernel: [] [] [] [] [] [] > Aug 18 18:50:59 localhost kernel: [] [] [] [] [in_group_p+35/48] [path_release+21/64] > Aug 18 18:50:59 localhost kernel: [sys_chdir+160/208] [sys_tux+126/128] [system_call+51/56] > Aug 18 18:50:59 localhost kernel: > Aug 18 18:50:59 localhost kernel: Code: 0f 0b b4 04 66 da 27 c0 e9 e1 fd ff ff 90 8b 54 24 04 8b 42 > Aug 18 18:50:59 localhost kernel: Possibly unexpected TUX-thread exit(11) at c0107803? > Aug 18 18:50:59 localhost kernel: TUX: thread 0 stopping ... > Aug 18 18:50:59 localhost kernel: PRINT req c6960800 , sock 00000000 > Aug 18 18:50:59 localhost kernel: ... idx: 0 > Aug 18 18:50:59 localhost kernel: ... meth:{}, uri:{}, query:{}, ver:{} > Aug 18 18:50:59 localhost kernel: ... post_data:{}(0). > Aug 18 18:50:59 localhost kernel: ... headers: {} > Aug 18 18:50:59 localhost kernel: PRINT req c6960800 , sock 00000000 > Aug 18 18:50:59 localhost kernel: ... idx: 0 > Aug 18 18:50:59 localhost kernel: ... meth:{}, uri:{}, query:{}, ver:{} > Aug 18 18:50:59 localhost kernel: ... post_data:{}(0). > Aug 18 18:50:59 localhost kernel: ... headers: {} > > The PRINT req message repeats infinitely, the machine needs to be rebooted > in order to be able to do anything with tux. > The interesting thing is that the redirect does take place, the backend > server does deliver content and only after that the above happens. I ran tux > userland under gdb since I suspected a segfault in the module somewhere (in > the original on), but no segfault happened and the test module confirmed > that it must have been something else. > > The line in inode.c says: > > if (inode->i_state == I_CLEAR) > BUG(); > > but I'm not sure what inode does tux trying to put - at first I thought that > it might have been a problem with the socket being killed prematurely but > the above oops trace suggests it has something to do with the filesystem on > disk (or /proc, perhaps?), I think. Any help will be appreciated, if more > info/testing is needed - please let me know > > TIA, > > marek > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From mingo at elte.hu Mon Sep 13 20:28:00 2004 From: mingo at elte.hu (Ingo Molnar) Date: Mon, 13 Sep 2004 22:28:00 +0200 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <1095085036.10027.20.camel@localhost.localdomain> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> <1095085036.10027.20.camel@localhost.localdomain> Message-ID: <20040913202800.GA20785@elte.hu> * William Lovaton wrote: > Ingo, > > El vie, 10-09-2004 a las 15:14, fredrik danerklint escribi?: > > However, I have another problem now with tux. Can it handle files which is an > > link? Everytime I access an link, tux crashes. Both the http and ftp server. > > This is what I've got from dmesg: > > Regarding my bug: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125091 > > I use a link too. I have always used it that way, it worked fine in > RedHat 9. May be Frederik's crash is not related but I just wanted to > comment that. symbolic links are supposed to work just fine (just like any other VFS object) but apparently there's a buglet in the 2.6 Tux version. Could you try to replace your symbolic link and see whether the Tux crashes you see still occur? Ingo From williama_lovaton at coomeva.com.co Mon Sep 13 22:36:27 2004 From: williama_lovaton at coomeva.com.co (William Lovaton) Date: 13 Sep 2004 17:36:27 -0500 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <20040913202800.GA20785@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> <1095085036.10027.20.camel@localhost.localdomain> <20040913202800.GA20785@elte.hu> Message-ID: <1095114986.11386.12.camel@localhost.localdomain> Hi Ingo, El lun, 13-09-2004 a las 15:28, Ingo Molnar escribi?: > * William Lovaton wrote: > > > Ingo, > > > > El vie, 10-09-2004 a las 15:14, fredrik danerklint escribi?: > > > However, I have another problem now with tux. Can it handle files which is an > > > link? Everytime I access an link, tux crashes. Both the http and ftp server. > > > This is what I've got from dmesg: > > > > Regarding my bug: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125091 > > > > I use a link too. I have always used it that way, it worked fine in > > RedHat 9. May be Frederik's crash is not related but I just wanted to > > comment that. > > symbolic links are supposed to work just fine (just like any other VFS > object) but apparently there's a buglet in the 2.6 Tux version. Could > you try to replace your symbolic link and see whether the Tux crashes > you see still occur? > > Ingo As soon as I can put my hands on a RPM kernel with TUX enabled I'll do it. Been checking http://people.redhat.com/arjanv/2.6/RPMS.kernel/ for a while and there is no sign of new RPMS, the last ones are Sept 7. In addition to the link change, I'll be testing your suggestions in this comment: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125091#c23 BTW, I have logging deactivated in TUX, I mean, the access log, etc. I have this configuration in /etc/sysctl.tux: net.tux.logging=0 net.tux.redirect_logging=0 net.tux.referer_logging=0 net.tux.documentroot=/var/www/html net.tux.compression=0 Should I add/remove/change something? Thanx, -William From mingo at elte.hu Wed Sep 15 19:54:27 2004 From: mingo at elte.hu (Ingo Molnar) Date: Wed, 15 Sep 2004 21:54:27 +0200 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <1095114986.11386.12.camel@localhost.localdomain> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> <1095085036.10027.20.camel@localhost.localdomain> <20040913202800.GA20785@elte.hu> <1095114986.11386.12.camel@localhost.localdomain> Message-ID: <20040915195426.GA17469@elte.hu> * William Lovaton wrote: > As soon as I can put my hands on a RPM kernel with TUX enabled I'll do > it. Been checking http://people.redhat.com/arjanv/2.6/RPMS.kernel/ > for a while and there is no sign of new RPMS, the last ones are Sept > 7. update: Arjan has fixed Tux in the RPM tree today - there were a number of nontrivial kernel infrastructure changes in the upstream kernel that made this more complex than first anticipated. The next RPM should happen tomorrow (barring any unforeseen problems). > BTW, I have logging deactivated in TUX, I mean, the access log, etc. I > have this configuration in /etc/sysctl.tux: > > net.tux.logging=0 > net.tux.redirect_logging=0 > net.tux.referer_logging=0 > net.tux.documentroot=/var/www/html > net.tux.compression=0 > > Should I add/remove/change something? looks good. Generally the defaults should work just fine. Ingo From arjanv at redhat.com Wed Sep 15 20:12:46 2004 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 15 Sep 2004 22:12:46 +0200 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <20040915195426.GA17469@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> <1095085036.10027.20.camel@localhost.localdomain> <20040913202800.GA20785@elte.hu> <1095114986.11386.12.camel@localhost.localdomain> <20040915195426.GA17469@elte.hu> Message-ID: <1095279166.2698.10.camel@laptop.fenrus.com> On Wed, 2004-09-15 at 21:54, Ingo Molnar wrote: > * William Lovaton wrote: > > > As soon as I can put my hands on a RPM kernel with TUX enabled I'll do > > it. Been checking http://people.redhat.com/arjanv/2.6/RPMS.kernel/ > > for a while and there is no sign of new RPMS, the last ones are Sept > > 7. > > update: Arjan has fixed Tux in the RPM tree today - there were a number > of nontrivial kernel infrastructure changes in the upstream kernel that > made this more complex than first anticipated. The next RPM should > happen tomorrow (barring any unforeseen problems).] actually the machine I upload this from got power back and the rsync is going right now... -------------- 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 mingo at elte.hu Fri Sep 17 10:15:13 2004 From: mingo at elte.hu (Ingo Molnar) Date: Fri, 17 Sep 2004 12:15:13 +0200 Subject: [patch] tux3-2.6.9-rc2-A2 In-Reply-To: <20040910193630.GB19488@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <20040910162028.GQ24408@krispykreme> <20040910193630.GB19488@elte.hu> Message-ID: <20040917101513.GA18752@elte.hu> i've uploaded the 2.6.9-rc2-A0 patch: http://redhat.com/~mingo/TUX-patches/tux3-2.6.9-rc2-A2 Changes: - merge to 2.6.9-rc2 (Arjan van de Ven) - cleaned up the Anton/akpm optimization: removed f_last_index from struct file and moved it to logger.c. (me) - cleaned up CGI execution - using kernel/kmod.c's infrastructure now. (me) Ingo From jspitz777 at yahoo.com Fri Sep 17 20:43:27 2004 From: jspitz777 at yahoo.com (John Spitz) Date: Fri, 17 Sep 2004 13:43:27 -0700 (PDT) Subject: Problem compiling tux3-2.6.8.1-A4 (x86_64) Message-ID: <20040917204327.28353.qmail@web53903.mail.yahoo.com> Hi all I am currently running FC2 with kernel 2.6.8.1 x86_64 I applied tux3-2.6.8.1-A4 to a fresh linux-2.6.8.1 source tree and tried compiling the kernel but I get an error. Here is the sequence of events: make bzImage succeeds make modules fails with this some warnings and ultimate with error: net/tux/accept.c: In function `kmalloc_req': net/tux/accept.c:150: warning: int format, different type arg (arg 4) net/tux/accept.c:150: warning: int format, different type arg (arg 4) CC [M] net/tux/input.o CC [M] net/tux/userspace.o CC [M] net/tux/cachemiss.o CC [M] net/tux/output.o CC [M] net/tux/redirect.o CC [M] net/tux/postpone.o CC [M] net/tux/logger.o net/tux/logger.c: In function `writeout_log': net/tux/logger.c:741: error: structure has no member named `f_last_index' net/tux/logger.c:742: error: structure has no member named `f_last_index' make[2]: *** [net/tux/logger.o] Error 1 make[1]: *** [net/tux] Error 2 make: *** [net] Error 2 Has anyone seen this error or can shed some light? Much appreciated John _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From mingo at elte.hu Sat Sep 18 09:25:57 2004 From: mingo at elte.hu (Ingo Molnar) Date: Sat, 18 Sep 2004 11:25:57 +0200 Subject: [patch] tux3-2.6.8.1-A5, tux3-2.6.9-rc2-A5 In-Reply-To: <20040917204327.28353.qmail@web53903.mail.yahoo.com> References: <20040917204327.28353.qmail@web53903.mail.yahoo.com> Message-ID: <20040918092557.GA32548@elte.hu> * John Spitz wrote: > Hi all > > I am currently running FC2 with kernel 2.6.8.1 x86_64 > > I applied tux3-2.6.8.1-A4 to a fresh linux-2.6.8.1 source tree and > tried compiling the kernel but I get an error. i fixed this in the -A5 patches: http://people.redhat.com/mingo/TUX-patches/tux3-2.6.8.1-A5 http://people.redhat.com/mingo/TUX-patches/tux3-2.6.9-rc2-A5 i merged back all the other fixes from the 2.6.9-rc2 Tux patch too, so the two should now be equivalent. Ingo From mingo at elte.hu Sat Sep 18 09:42:56 2004 From: mingo at elte.hu (Ingo Molnar) Date: Sat, 18 Sep 2004 11:42:56 +0200 Subject: Problem compiling tux3-2.6.8.1-A4 (x86_64) In-Reply-To: <20040917204327.28353.qmail@web53903.mail.yahoo.com> References: <20040917204327.28353.qmail@web53903.mail.yahoo.com> Message-ID: <20040918094256.GA11876@elte.hu> * John Spitz wrote: > Hi all > > I am currently running FC2 with kernel 2.6.8.1 x86_64 > > I applied tux3-2.6.8.1-A4 to a fresh linux-2.6.8.1 source tree and > tried compiling the kernel but I get an error. btw., if you are running FC2 then you could try Arjan's FC3 test-kernels - it has latest Tux included and there are x64 rpms too: http://people.redhat.com/arjanv/2.6/RPMS.kernel/ or add this to /etc/yum.conf: [2.6testkernels] name=Test Linux 2.6-test prerelease kernels for FC3 baseurl=http://people.redhat.com/arjanv/2.6 and type 'yum update'. (they are testkernels but track the upstream kernel very closely.) Ingo From jspitz777 at yahoo.com Sat Sep 18 18:48:06 2004 From: jspitz777 at yahoo.com (John Spitz) Date: Sat, 18 Sep 2004 11:48:06 -0700 (PDT) Subject: Problem compiling tux3-2.6.8.1-A4 (x86_64) In-Reply-To: <20040918094256.GA11876@elte.hu> Message-ID: <20040918184806.74134.qmail@web53906.mail.yahoo.com> Ingo, Thanks a lot for the 2.6.8.1 patch fix. It compiled and runs fine. I'll also try Arjan's FC3 test-kernels in the near future. Regards John --- Ingo Molnar wrote: > > * John Spitz wrote: > > > Hi all > > > > I am currently running FC2 with kernel 2.6.8.1 > x86_64 > > > > I applied tux3-2.6.8.1-A4 to a fresh linux-2.6.8.1 > source tree and > > tried compiling the kernel but I get an error. > > btw., if you are running FC2 then you could try > Arjan's FC3 test-kernels > - it has latest Tux included and there are x64 rpms > too: > > http://people.redhat.com/arjanv/2.6/RPMS.kernel/ > > or add this to /etc/yum.conf: > > [2.6testkernels] > name=Test Linux 2.6-test prerelease kernels for FC3 > baseurl=http://people.redhat.com/arjanv/2.6 > > and type 'yum update'. (they are testkernels but > track the upstream > kernel very closely.) > > Ingo > > > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From williama_lovaton at coomeva.com.co Mon Sep 20 22:35:23 2004 From: williama_lovaton at coomeva.com.co (William Lovaton) Date: 20 Sep 2004 17:35:23 -0500 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <20040915195426.GA17469@elte.hu> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> <1095085036.10027.20.camel@localhost.localdomain> <20040913202800.GA20785@elte.hu> <1095114986.11386.12.camel@localhost.localdomain> <20040915195426.GA17469@elte.hu> Message-ID: <1095719719.11384.111.camel@localhost.localdomain> El mi? 15-09-2004 a las 14:54, Ingo Molnar escribi?: > * William Lovaton wrote: > > > As soon as I can put my hands on a RPM kernel with TUX enabled I'll do > > it. Been checking http://people.redhat.com/arjanv/2.6/RPMS.kernel/ > > for a while and there is no sign of new RPMS, the last ones are Sept > > 7. > > update: Arjan has fixed Tux in the RPM tree today - there were a number > of nontrivial kernel infrastructure changes in the upstream kernel that > made this more complex than first anticipated. The next RPM should > happen tomorrow (barring any unforeseen problems). Ingo, Does this mean that I don't have to apply this patch you sent me? --- net/tux/abuf.c.orig +++ net/tux/abuf.c @@ -157,7 +157,8 @@ repeat: req->abuf.page, req->abuf.buf, req->abuf.size, req->abuf.offset, req->abuf.flags); - __free_page(req->abuf.page); + if (req->abuf.page) + __free_page(req->abuf.page); memset(&req->abuf, 0, sizeof(req->abuf)); When you say that it is fixed in the RPM tree, does that mean that I can install it through yum once it is available?? -William From bkesuma at ml.gaijinweb.com Tue Sep 21 06:42:54 2004 From: bkesuma at ml.gaijinweb.com (Batara Kesuma) Date: Tue, 21 Sep 2004 15:42:54 +0900 Subject: 404 Error Message-ID: <20040921154254.3fbb29c9.bkesuma@ml.gaijinweb.com> Hi, I just noticed that my TUX server doesn't return 404 even if the file doesn't exist. No error, the browser just keeps loading until time out. My TUX version: tux-3.2.18-1 [root at ternate run]# cat /etc/sysctl.tux net.tux.mode_allowed = 400 net.tux.generate_cache_control = 1 net.tux.generate_etags = 1 net.tux.generate_last_mod = 1 Any idea? Thank you very much. --bk From mingo at elte.hu Tue Sep 21 07:52:41 2004 From: mingo at elte.hu (Ingo Molnar) Date: Tue, 21 Sep 2004 09:52:41 +0200 Subject: [patch] tux3-2.6.8.1-A3 In-Reply-To: <1095719719.11384.111.camel@localhost.localdomain> References: <20040419070756.GA15513@elte.hu> <20040909170618.GA27795@elte.hu> <200409102214.02264.fredan-tux@fredan.org> <1095085036.10027.20.camel@localhost.localdomain> <20040913202800.GA20785@elte.hu> <1095114986.11386.12.camel@localhost.localdomain> <20040915195426.GA17469@elte.hu> <1095719719.11384.111.camel@localhost.localdomain> Message-ID: <20040921075241.GA12856@elte.hu> * William Lovaton wrote: > Ingo, Does this mean that I don't have to apply this patch you sent > me? this patch is not yet in Arjan's RPM - should be in the next RPM - i.e. in the one that comes after 584. Ingo From mcd at daviesinc.com Tue Sep 21 17:30:01 2004 From: mcd at daviesinc.com (Chris Davies) Date: Tue, 21 Sep 2004 13:30:01 -0400 Subject: 404 Error In-Reply-To: <20040921154254.3fbb29c9.bkesuma@ml.gaijinweb.com> References: <20040921154254.3fbb29c9.bkesuma@ml.gaijinweb.com> Message-ID: <1095787802.1590.31.camel@mcdlp.pbi.daviesinc.com> On Tue, 2004-09-21 at 15:42 +0900, Batara Kesuma wrote: > I just noticed that my TUX server doesn't return 404 even if the file > doesn't exist. No error, the browser just keeps loading until time out. is the file named 404.html and in the root of the document? are you sure it just keeps loading or is it doing redirects? If you're using IE, is the 404.html document padded to 520+ bytes so that the smart error messages don't kick in? telnet port 80 GET /asdf HTTP/1.0 see what it returns -- I'm guessing it probably returns a 302 rather than a 404. What does the tux log say? is it redirecting it to the backend?