From chair123 at 21cn.com Fri Jun 9 09:05:02 2006 From: chair123 at 21cn.com (chair) Date: Fri, 9 Jun 2006 17:05:02 +0800 (CST) Subject: where can i download the user space program for tux3-2.6.16? Message-ID: An HTML attachment was scrubbed... URL: From chair123 at 21cn.com Fri Jun 9 17:02:22 2006 From: chair123 at 21cn.com (Chair) Date: Sat, 10 Jun 2006 01:02:22 +0800 Subject: Coulld anyone tell me how to download the userspace program of tux? Message-ID: <00939389989483.10329@send1.inner-21cn.com> tux-list? I can't find anything about tux userspace program for tux3-2.6.16A, could anyone give me a hand? thx at all:) ???????? ????????Chair ????????chair123 at 21cn.com ??????????2006-06-10 From kyrian at ore.org Thu Jun 15 15:45:20 2006 From: kyrian at ore.org (Kyrian) Date: Thu, 15 Jun 2006 16:45:20 +0100 Subject: TUX kernel panic - directory for log file doesn't exist...? Message-ID: <44918090.7080506@ore.org> All, If indeed there is anyone alive on here, I've just found out something 'interesting'... If you are dumb enough (hey, I was in a hurry ;-) to start up TUX without a directory existing in which to write to its log file (pretty certainly different to just having a missing logfile in kernel terms), it starts up, with a warning of (edited for security, of course): Jun 14 15:25:50 XYZ kernel: TUX: logger thread started. Jun 14 15:25:50 XYZ kernel: TUX: could not open log file {ABC.../access_log_tux}! Jun 14 15:25:50 XYZ kernel: TUX: thread 0 listens on http://X.Y.Z.K:80. It then goes on to work just fine, but when you try and stop it again, you get a kernel panic, as follows. Anyways, I just thought it might be a better idea to have TUX fail to start if it can't find a log file, rather than crash the machine out with a kernel panic when you try and stop it. Or of course the underlying problem could be fixed. K. Jun 15 02:45:24 XYZ kernel: TUX: thread 0 stopping ... Jun 15 02:45:24 XYZ kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000020 Jun 15 02:45:24 XYZ kernel: printing eip: Jun 15 02:45:24 XYZ kernel: f8a9fbef Jun 15 02:45:24 XYZ kernel: *pde = 00000000 Jun 15 02:45:24 XYZ kernel: Oops: 0002 [#1] Jun 15 02:45:24 XYZ kernel: last sysfs file: /block/hda/hda1/size Jun 15 02:45:24 XYZ kernel: Modules linked in: ip_conntrack_netbios_ns xt_state ip_conntrack nfnetlink iptable_filter ip_tables tux zlib_deflate ipv6 autofs4 hidp rfcomm l2cap bluetooth sunrpc ipt_LOG ipt_REJECT xt_tcpudp x_tables dm_mirror dm_mod video button battery ac lp parport_pc parport floppy nvram 8139too 8139cp mii i2c_i810 i2c_algo_bit i2c_i801 i2c_core uhci_hcd ehci_hcd raid1 ext3 jbd Jun 15 02:45:24 XYZ kernel: CPU: 0 Jun 15 02:45:24 XYZ kernel: EIP: 0060:[] Not tainted VLI Jun 15 02:45:24 XYZ kernel: EFLAGS: 00010246 (2.6.16-1.2096_FC5 #1) Jun 15 02:45:24 XYZ kernel: EIP is at tux_flush_workqueue+0x68/0xd3 [tux] Jun 15 02:45:24 XYZ kernel: eax: 00000000 ebx: f7289800 ecx: f8ab8168 edx: f1891000 Jun 15 02:45:24 XYZ kernel: esi: f8ab7fc0 edi: f8ab8158 ebp: 00000000 esp: f03beaac Jun 15 02:45:24 XYZ kernel: ds: 007b es: 007b ss: 0068 Jun 15 02:45:24 XYZ kernel: Process tux (pid: 1856, threadinfo=f03be000 task=f1891000) Jun 15 02:45:24 XYZ kernel: Stack: <0>f8ab8134 f8ab8134 f8ab7fc0 00000000 f8aa933b 00000002 f8ab8080 f8ab8110 Jun 15 02:45:24 XYZ kernel: 00000000 f8ab7fc0 f8aaa647 c02dd5cd c02dc257 e8af7000 00000009 f1891128 Jun 15 02:45:24 XYZ kernel: f6853550 5d013800 003d2e12 00000000 d0f43000 c02dd5cd 003d0900 00000000 Jun 15 02:45:24 XYZ kernel: Call Trace: Jun 15 02:45:24 XYZ kernel: [] flush_all_requests+0x5d/0xa1 [tux] [] __sys_tux+0x809/0x1101 [tux] Jun 15 02:45:24 XYZ kernel: [] _spin_unlock_irq+0x5/0x7 [] schedule+0x4a1/0x4ff Jun 15 02:45:24 XYZ kernel: [] _spin_unlock_irq+0x5/0x7 [] __sys_tux+0x10f1/0x1101 [tux] Jun 15 02:45:24 XYZ kernel: [] get_page_from_freelist+0x6f/0x2db [] get_page_from_freelist+0x6f/0x2db Jun 15 02:45:24 XYZ kernel: [] _atomic_dec_and_lock+0x22/0x2c [] __alloc_pages+0x66/0x26c Jun 15 02:45:24 XYZ kernel: [] _read_unlock_irq+0x5/0x7 [] find_get_page+0x39/0x3f Jun 15 02:45:24 XYZ kernel: [] filemap_nopage+0x165/0x2ea [] __handle_mm_fault+0x41d/0x7c3 Jun 15 02:45:24 XYZ kernel: [] do_exit+0x19e/0x6c8 [] sys_exit_group+0x0/0xd Jun 15 02:45:24 XYZ kernel: [] syscall_call+0x7/0xb <0>Code: 0f 0b a7 00 54 de aa f8 8b 02 39 50 04 74 08 0f 0b a8 00 54 de aa f8 89 48 04 89 01 89 12 89 52 04 89 f8 e8 dc d9 83 c7 8b 43 6c 40 20 00 00 00 00 c7 40 24 00 00 00 00 c7 43 04 00 00 00 00 Jun 15 02:45:24 XYZ kernel: Continuing in 120 seconds. ^MContinuing in 119 seconds. ^MContinuing in 118 seconds. [ etc. with random intervals of seconds ] Jun 15 02:45:24 XYZ kernel: <0>Fatal exception: panic in 5 seconds From cyt0plas at gmail.com Sat Jun 17 23:26:39 2006 From: cyt0plas at gmail.com (Carlos Averett) Date: Sat, 17 Jun 2006 16:26:39 -0700 Subject: Sporadic Tux Failures Message-ID: <2a826d510606171626k4b49ac4r9c9fdf5b616f592f@mail.gmail.com> I've currently got lighttpd serving the dynamic content, and am trying to get tux to serve all the static content (gifs, jpegs, css, etc). For some reason, tux randomly hands off files to the userland HTTP server, causing this setup to break. It's not particularly consistant, either. For example, I have a test page with 4 gifs, and a .css file. Every time I reload, some of the images/css don't load, while others do. Each reload brings a new page, as I never know what will actually be handled by tux, and what will be passed on. I've read through the documentation, and have tried disabling keep-alives, to no avail. Has anyone else experienced this problem, and been able to resolve it? From wms at igoweb.org Sun Jun 18 00:40:23 2006 From: wms at igoweb.org (William M. Shubert) Date: Sat, 17 Jun 2006 17:40:23 -0700 Subject: Sporadic Tux Failures In-Reply-To: <2a826d510606171626k4b49ac4r9c9fdf5b616f592f@mail.gmail.com> References: <2a826d510606171626k4b49ac4r9c9fdf5b616f592f@mail.gmail.com> Message-ID: <1150591224.13066.15.camel@desktop.igoweb.org> On Sat, 2006-06-17 at 16:26 -0700, Carlos Averett wrote: > I've currently got lighttpd serving the dynamic content, and am trying > to get tux to serve all the static content (gifs, jpegs, css, etc). > For some reason, tux randomly hands off files to the userland HTTP > server, causing this setup to break. It's not particularly > consistant, either. > > For example, I have a test page with 4 gifs, and a .css file. Every > time I reload, some of the images/css don't load, while others do. > Each reload brings a new page, as I never know what will actually be > handled by tux, and what will be passed on. > > I've read through the documentation, and have tried disabling > keep-alives, to no avail. Has anyone else experienced this problem, > and been able to resolve it? You mean that you will reload a page, and the files handled by tux changes with each reload? Or is it reliable, "xxx.gif" is always handled by Tux, while "yyy.gif" is always handled by lighttpd? If the former, then the only thing I can think of is keep-alives. Try using something like wget, fetching each file with a separate instance, and if that forces all files to be tux, then you know it is the keep-alives. If it is *still* unreliable whether xxx.gif gets loaded by tux or lighttpd, then you have a real mystery on your hands! If the latter, then just look very carefully for differences in the files. Tux is picky about protection flags, that may be it, or if you have symbolic links it is possible that a link leads out of tux's root area. At one time I was having issues so I instrumented Tux with printk() calls at each decision. It was very helpful in clearing up mysteries like this. I don't have that copy of Tux around any more, but it is easy to make - Tux isn't very big, so instrumenting each decision only takes about 15-20 minutes to do. Then compile, install, and run your test, and the mystery will be solved. Make sure you put back standard Tux afterwards, or your kernel logs will quickly fill up your whole disk once you enter production! From kyrian at ore.org Wed Jun 28 21:26:03 2006 From: kyrian at ore.org (Kyrian) Date: Wed, 28 Jun 2006 22:26:03 +0100 Subject: TUX kernel panic - directory for log file doesn't exist...? In-Reply-To: <449232B3.90208@daviesinc.com> References: <44918090.7080506@ore.org> <449232B3.90208@daviesinc.com> Message-ID: <44A2F3EB.1070707@ore.org> Chris, List, > What kernel are you using and what tux version? [root at gibson ~]# rpm -q kernel kernel-2.6.17-1.2139_FC5 [root at gibson ~]# rpm -q tux tux-3.2.18-4.2.1 [root at gibson ~]# As you can gather, its running Fedora Core 5. Unfortunately I just tried to restart TUX to make sure that the RPM-reported version was the one actually running, and the below crash occured, which has hung the whole box except the core IP stack. The kernel is not an SMP one, to the best of my knowledge. > I am reasonably sure this error occurs from running on 2.6 SMT/SMP > rather than from the log directory/logfile not existing. *nods* > For SMP, we've only had luck with 2.4. With 2.6, we've had to force > the kernel to UniProcessor. Okay, well, its a single processor box, and I'm pretty sure it isn't running an SMP kernel. Also weirdly I have been experiencing odd (I presume network-only) lockups on this box since it started serving the site it was meant to in a live capacity. I couldn't find any debug info to indicate why this was. It's a brand new server that was pretty thoroughly tested and was fine until the site went live with TUX and Apache. Any help would be much appreciated. Here's what happened at the above TUX restart :( Message from syslogd at gibson at Wed Jun 28 22:17:19 2006 ... gibson kernel: Oops: 0002 [#1] Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: CPU: 0 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: EIP is at tux_flush_workqueue+0xa2/0x115 [tux] Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: eax: 00000000 ebx: ca97f028 ecx: 00000000 edx: f747a000 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: esi: ca97f000 edi: f8a7b740 ebp: f8a7b8d8 esp: f6841a80 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: ds: 007b es: 007b ss: 0068 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: Process tux (pid: 27110, threadinfo=f6841000 task=f747a000) Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: Stack: f8a7b740 00000286 00000286 00000000 f8a7b8b4 f8a7b8b4 f8a7b740 00000000 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: f8a6ae79 00000001 f8a7b800 f8a7b890 f6841000 f8a7b740 f8a6c1ab f8a712f8 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: 00000000 c0768460 00000000 c0601935 c05ff8b4 01010000 0000000a f747a11c Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: Call Trace: Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: flush_all_requests+0x5d/0xa1 [tux] __sys_tux+0x824/0x111d [tux] Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: _spin_unlock_irq+0x5/0x7 schedule+0x526/0x582 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: __sys_tux+0x110d/0x111d [tux] get_page_from_freelist+0x26e/0x3d7 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: get_page_from_freelist+0x26e/0x3d7 get_page_from_freelist+0x36a/0x3d7 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: __alloc_pages+0x6d/0x29c _read_unlock_irq+0x5/0x7 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: find_get_page+0x39/0x3f filemap_nopage+0x16e/0x2f8 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: __handle_mm_fault+0x41c/0x7ed _atomic_dec_and_lock+0x22/0x2c Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: tux_exit+0x17/0x1a [tux] do_exit+0x19b/0x768 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: sys_exit_group+0x0/0xd syscall_call+0x7/0xb Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: Code: 24 4b fd a6 f8 e8 55 b9 9b c7 0f 0b b9 00 36 fd a6 f8 8b 43 04 8b 13 89 42 04 89 10 89 e8 89 1b 89 5b 04 e8 a4 08 ba c7 8b 46 6c 40 20 00 00 00 00 c7 40 24 00 00 00 00 80 be ec 00 00 00 00 Message from syslogd at gibson at Wed Jun 28 22:17:20 2006 ... gibson kernel: EIP: [] tux_flush_workqueue+0xa2/0x115 [tux] SS:ESP 0068:f6841a80 K. From kyrian at ore.org Wed Jun 28 22:24:13 2006 From: kyrian at ore.org (Kyrian) Date: Wed, 28 Jun 2006 23:24:13 +0100 Subject: TUX kernel panic - directory for log file doesn't exist...? (additional) Message-ID: <44A3018D.7070208@ore.org> All, Well, although it's not an SMP kernel *package* there were still reports of SMP tomfoolery in the output of dmesg, as follows: ... found SMP MP-table at 000f4ca0 Using x86 segment limits to approximate NX protection ... Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 40000000 (gap: 3ff00000:bed00000) ... Therefore I have taken the (usually sane) step of disabling APIC and ACPI in the kernel parameters, and will see if this stops the random lockups. This has had the effect of removing the latter section's reference to SMP, what that means in english, I have very little idea ;-) I'm not going to risk restarting TUX again without a reboot because I don't want to lose the damn server. This vexes me though. I've never had any problems with it before, and it's worked like a charm (on single processor boxes, or quad processor ones, although having just checked, both sites are running 2.4 kernels). Are there any other caveats I need to know about, or is it just with 2.6 kernels? K.