userspace modules configuration problem and an oops

[Kees Hoekzema]

On Tuesday 16 November 2004 04:28, Marek Habersack wrote:
> While testing the above, I've also came across another problem, this time
> an oops (tux A6):
>
> Nov 15 21:50:14 colo6 kernel: kernel BUG at fs/namei.c:481!
[snip]
> kernel_thread_helper+0x5/0x18 Nov 15 21:50:14 colo6 kernel: Code: 1a 01 22
> c1 34 c0 eb ec 0f 0b 1a 01 22 c1 34 c0 eb 98 89 2c 24 e8 74 f2 ff ff 8 9 f0
> e9 4c fe ff ff e8 d8 b8 1e 00 e9 a7 fd ff ff <0f> 0b e1 01 ec ec 34 c0 e9
> 8f fd ff ff 89 2c 24 e8 4e f2 ff ff
>
> It happens whenever a request is made that resolves to a symlink on the
> filesystem (XFS in our case). After the oops tux cannot be stopped and the
> machine must be rebooted.

I have the same problem discribed here, the box stays up, but tux cant be 
stopped and I need to reboot the server. As we have quite a lot symlinks it 
is quite a showstopper at the moment.

I tried to run tux with debugging, Dprintk seems not to send enough debug 
info, TDprintk does, but creates an kernel panic (after which my system 
freezes and needs a remote powercycle).

Than I tried to get some debugging with only Dprintk, and changing a few lines 
in input.c and http_proto.c so it used printk instead of Dprintk. This 
somehow fixed the problem where tux crashed..

I added some printk's when this tux_lookup was called and somehow that fixed 
my problem. I'm not sure what exactly is fixed; The only thing I changed was 
on line 781 in proto_http.c where I changed 'Dprintk' to 'printk'. (which is 
now filling up my dmesg ;))

Changing it back resulted in the same bug returning.

Maybe someone more experienced in Tux-hacking can explain it.

-kees


info:
My complete message:
kernel BUG at fs/namei.c:481!
invalid operand: 0000 [#1]
SMP
Modules linked in:
CPU:    0
EIP:    0060:[<c0153de0>]    Not tainted VLI
EFLAGS: 00010286   (2.6.9)
EIP is at link_path_walk+0x493/0xd60
eax: e4b270d0   ebx: f28e33c8   ecx: c01abfe0   edx: eb597e60
esi: eb597000   edi: f2c49288   ebp: f4f2d1c5   esp: eb597e00
ds: 007b   es: 007b   ss: 0068
Process tux (pid: 502, threadinfo=eb597000 task=e4b270d0)
Stack: 00000040 eb597e18 00000272 f3b03d74 eb597e4c ffffffd8 8e711f53 00000001
       00000040 eb597e60 f6d83780 f28e33c8 db6490ae 00000007 f4f2d1bd 00000000
       eb597e60 f4f2d1b0 00000040 f4f2d000 c02f783f f4f2d000 c02f7930 eb597ee4
Call Trace:
 [<c02f783f>] __tux_lookup+0xc/0x1d
 [<c02f7930>] tux_lookup+0xa6/0xf0
 [<c01129ef>] task_rq_lock+0x36/0x64
 [<c0113177>] try_to_wake_up+0x1ce/0x24d
 [<c02fc586>] lookup_url+0x52/0x54e
 [<c02f68ef>] add_req_to_workqueue+0x2c/0x43
 [<c02f7bb7>] unidle_req+0x68/0x6a
 [<c02fdbd3>] http_process_message+0x61/0x2de
 [<c02f763e>] tux_schedule_atom+0xe/0x10
 [<c02f8461>] process_requests+0xad/0xb8
 [<c03032e3>] event_loop+0x131/0x18c
 [<c0304aa1>] __sys_tux+0x1f7/0x841
 [<c0146b5a>] sys_chdir+0x5d/0x6b
 [<c0103be7>] syscall_call+0x7/0xb
Code: eb d1 0f 0b 1a 01 f1 31 33 c0 e9 49 ff ff ff 8b 44 24 24 e8 91 f7 ff ff 
8b 44 24 10 e9 e2 fd ff ff e8 3e 9f 1c 00 e9 2b fd ff ff <0f> 0b e1 01 b9 66 
33 c0 e9 13 fd ff ff 8b 44 24 24 e8 68 f7 ff

System config:
Dual Xeon 2.8GHz w/ 1GB ram
60G IDE disk
uname -a:
Linux argus 2.6.9 #6 SMP Sun Nov 28 01:37:10 CET 2004 i686 unknown unknown 
GNU/Linux

2.6.9 is running tux, with the small change Julien Lirochon suggested in his 
mail to this list.