[patch] tux3-2.6.8.1-A3

[fredrik danerklint]

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:[<c014c541>]    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:
 [<e08ca330>] __tux_lookup+0x10/0x30 [tux]
 [<e08ca43d>] tux_lookup+0xad/0xf0 [tux]
 [<c010f4e1>] activate_task+0x51/0x70
 [<c010f5ac>] try_to_wake_up+0x3c/0x90
 [<e08cf35e>] lookup_url+0x6e/0x5f0 [tux]
 [<c010f60d>] wake_up_process+0xd/0x10
 [<e08c952e>] add_req_to_workqueue+0xe/0x20 [tux]
 [<e08d096a>] http_lookup_vhost+0xda/0x120 [tux]
 [<c0251aa3>] schedule+0x93/0x460
 [<e08d09f8>] http_process_message+0x48/0x2b0 [tux]
 [<e08ca0a9>] tux_schedule_atom+0x29/0x50 [tux]
 [<e08cb189>] cachemiss_thread+0x139/0x1b0 [tux]
 [<c010fe40>] default_wake_function+0x0/0x20
 [<c010fe40>] default_wake_function+0x0/0x20
 [<e08cb050>] cachemiss_thread+0x0/0x1b0 [tux]
 [<c0101eb5>] 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:[<c014c541>]    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:
 [<c010f3f1>] recalc_task_prio+0x161/0x200
 [<e08ca330>] __tux_lookup+0x10/0x30 [tux]
 [<e08ca43d>] tux_lookup+0xad/0xf0 [tux]
 [<c0251aa3>] schedule+0x93/0x460
 [<e08d3dd9>] ftp_chdir+0x29/0x110 [tux]
 [<e08ca0a9>] tux_schedule_atom+0x29/0x50 [tux]
 [<e08cb189>] cachemiss_thread+0x139/0x1b0 [tux]
 [<c010fe40>] default_wake_function+0x0/0x20
 [<c010fe40>] default_wake_function+0x0/0x20
 [<e08cb050>] cachemiss_thread+0x0/0x1b0 [tux]
 [<c0101eb5>] 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] <defunct>
5353 ?        Z      0:00      \_ [async IO 0/2] <defunct>
5354 ?        Z      0:00      \_ [async IO 0/3] <defunct>
5355 ?        Z      0:00      \_ [async IO 0/4] <defunct>
5356 ?        Z      0:00      \_ [async IO 0/5] <defunct>
5357 ?        Z      0:00      \_ [async IO 0/6] <defunct>
5358 ?        Z      0:00      \_ [async IO 0/7] <defunct>
5359 ?        Z      0:00      \_ [async IO 0/8] <defunct>
5360 ?        S      0:00      \_ [TUX worker 0]


-- 
//fredan