On Wed, Jul 12, 2000 at 06:32:36PM +0200, System V wrote:
> tail -f /usr/coda/etc/venus.log
> [ W(25) : 0000 : 18:20:25 ] WAITING((0x7f000000.0x1.0x1)): level = RD,
> readers = 0, writers = 1
> [ W(26) : 0000 : 18:20:34 ] WAITING((0x7f000000.0x1.0x1)): level = RD,
> readers = 0, writers = 1
> [ W(27) : 0000 : 18:20:36 ] WAITING((0x7f000000.0x1.0x1)): level = RD,
> readers = 0, writers = 1
> [ W(28) : 0000 : 18:20:41 ] WAITING((0x7f000000.0x1.0x1)): level = RD,
> readers = 0, writers = 1
> [ W(29) : 0000 : 18:20:45 ] WAITING((0x7f000000.0x1.0x1)): level = RD,
> readers = 0, writers = 1

Brian Noble at one point identified a kernel problem that can cause this
situation. Upcalls from the kernel to venus are aborted when the process
triggering the upcall receives a ^C, this also happens for CLOSE upcalls.

In that case venus cannot correctly decrement the readers/writers.

> 18:30:26 /usr/coda/LOG validated at size 0x509200
> 18:30:26 /usr/coda/DATA validated at size 0x14232e0
> log_recover failed.
> do_rvm_options failed
> 18:30:26 fatal error -- Recov_InitRVM: RVM_INIT failed, internal error
> Current time before last recorded - check kernel date
> 18:30:26 Fatal Signal (11); pid 1696 becoming a zombie...
> 18:30:26 You may use gdb to attach to 1696

This is a different problem, your system clock is returning a time that
is before the last run of venus. This should never happen. Clocks
running `backwards' also tend to mess up building sourcecode, checking
for new email, etc.

> I'll just keep rebooting :-(

I don't reboot that often;
    killall -9 venus
    # kill all processes that have their cwd in /coda.
    umount /coda
    venus &

> Ps. is there a posability to work directly on the server,  eg cache
> size= 0 ??

No, Coda does not intercept kernel read/write calls, on the open call
the file is fetched into the cache, then we return it's device/ino to
the kernel and attach the containerfile inode to the coda inode. All
read/write calls go directly to the container file. That is a lot more
efficient because every upcall takes at least 2 context switches
(process->venus->process) and doing this for every read and write would
slow down the system tremendously.

Jan