Coda File System

venus death/codasrv problem?

From: Tom Tarka <tommy_at_mp3.com>
Date: Thu, 03 Feb 2000 19:55:13 -0800
I'm running a codaserver (v. 5.3.4) on a PowerPC MkLinux machine.

When I start venus on an intel RHL machine pointing at this server,
it pretends to connect, then just dies.  However, when I point at the
testserver, I have no problems -- so I assume it's a server issue.

Is there anything I can do to better find out what's happening?

    -t

Server output:

17:43:12 Set disk usage statistics
17:43:12 Entering VSetDiskUsage()
0x101e88d0 : Cop Pending Manager
17:43:12 LockQueue Manager woken up
17:43:12 LockQueue Manager sleeping for 60 seconds
17:43:40 Worker 3 received request -13 on cid 193272512 for NA at NA
17:43:40 in AL_NameToId(System:AnyUser)
17:43:40 in AL_GetInternalCPS(-101, 0x101ff3f4)
17:43:40 New connection received RPCid 193272512, security lvl 98, rem id 353160568

17:43:41 Worker 4 received request 40 on cid 193272512 for root at 10.0.0.4
17:43:41 FS_ViceNewConnectFS (version 3) for user root at sodom.slackers.net.venus
17:43:41 Building callback conn.
17:43:41 Probing existing WriteBack conn 34257c0e
17:43:41 RevokeWBPermit on conn 34257c0e returned -2016
17:43:41 No idle WriteBack conns, building new one
17:43:41 Writeback message to 10.0.0.4 port 2430 on conn 189b0ad4 succeeded
17:43:41 FS_ViceNewConnectFS returns Success
17:43:41 Worker 5 received request 15 on cid 193272512 for root at 10.0.0.4
17:43:41 ViceGetRootVolume
17:43:41 ViceGetRootVolume returns Success, Volume = coda.root
17:43:42 Worker 0 received request 24 on cid 193272512 for root at 10.0.0.4
17:43:42 ViceGetVolumeInfo volume = coda.root
17:43:42 ViceGetVolumeInfo returns Success, Volume 2130706432, type 3, servers
7f000001 0 0 0...
0x101e88d0 : Cop Pending Manager

Client output:

(tommy_at_sodom) ~ % sudo gdb venus
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...(no debugging symbols found)...
(gdb) run -init
Starting program: /usr/sbin/venus -init

Date: Thu 02/03/2000

17:40:38 /usr/coda/LOG setup for size 0xc7b74
17:40:38 /usr/coda/DATA initialized at size 0x31edd0
17:40:38 brain-wiping recoverable store
17:40:39 loading recoverable store
17:40:39 starting VSGDB scan
17:40:39        0 vsg entries in table
17:40:39        0 vsg entries on free-list
17:40:39 starting VDB scan
17:40:39        1 vol entries in table (0 MLEs)
17:40:39        0 vol entries on free-list (0 MLEs)
17:40:40 starting FSDB scan (1250, 30000) (25, 75, 4)
17:40:40        0 cache files in table (0 blocks)
17:40:40        1250 cache files on free-list
17:40:40 starting HDB scan
17:40:40        0 hdb entries in table
17:40:40        0 hdb entries on free-list
17:40:40 Kernel version ioctl failed (Inappropriate ioctl for device)!
17:40:40 2.3 or later kernels require an updated kernel module!
17:40:40 Initial LRDB allocation
17:40:40 Getting Root Volume information...
17:40:42 Venus starting...

Program terminated with signal SIGKILL, Killed.
The program no longer exists.
(gdb) bt
No stack.
Received on 2000-02-03 20:57:55