tux and coda?

has anyone tried using tux with coda? coda is a caching, shared
file system, based on AFS.

it seems that something about how tux tries to read files has
problems when running against files served by coda.

after running for a few minutes, i will get an "oops", and if
i try to kill tux, it hangs forever until i reboot the machine.

my gut feeling is that tux's caching is not playing nice with
coda's caching somehow.

anyway, if anyone here has any insights, they would be appreciated.

from ksymoops:

Unable to handle kernel NULL pointer dereference at virtual address 00000000
00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<00000000>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: c02eaa20   ebx: c218c19c   ecx: 00000000   edx: f5a6586c
esi: c144f040   edi: d9c5d690   ebp: 00000000   esp: f5db1f10
ds: 0018   es: 0018   ss: 0018
Process async IO 0/1 (pid: 1568, stackpage=f5db1000)
Stack: c012bfa0 f5a6586c c144f040 000000ce 00000001 00000000 00000000 d9c5d5e0
       00000038 0000001a 00000002 00000000 fffffffb f5a65800 f5a65800 00000000
       f89c6d82 f5a6586c f5a6588c f5a658d8 f89c6840 00000000 f5db1f70 00000000
Call Trace: [<c012bfa0>] [<f89c6d82>] [<f89c6840>] [<f89cbaeb>] [<f89c51a8>]
   [<f89c6468>] [<f89e5220>] [<c0105876>] [<f89c6320>]
Warning (Oops_read): Code line not seen, dumping what data is available

>>EIP; 00000000 Before first symbol
Trace; c012bfa0 <do_generic_file_read+2e0/480>
Trace; f89c6d82 <[tux]generic_send_file+e2/1d0>
Trace; f89c6840 <[tux]sock_send_actor+0/3b0>
Trace; f89cbaeb <[tux]http_send_body+6b/100>
Trace; f89c51a8 <[tux]tux_schedule_atom+18/20>
Trace; f89c6468 <[tux]cachemiss_thread+148/240>
Trace; f89e5220 <[tux]threadinfo+0/1340>
Trace; c0105876 <kernel_thread+26/30>
Trace; f89c6320 <[tux]cachemiss_thread+0/240>

-- 

steve simitzis : /sim' - i - jees/
          pala : saturn5 productions
 www.steve.org : 415.282.9979
  hath the daemon spawn no fire?