On Fri, Feb 16, 2007 at 07:44:29PM +0100, S. Cance wrote:
> Davor Ocelic wrote:
> >Yes, I had this problem with 64-bit client connecting to
> >testserver.coda.cs.cmu.edu as well.
> >
> >However, I suppose this was fixed in CVS a few days ago, when Jan reported
> >he fixed a small issue with clog.
> >
> >-doc
> >  
> I checked my sources and they seems to be up-to-date from the CVS 
> repository.
> Juste to be sure I build from the CVS sources the client & the server 
> again today, but my problem persist.

That is strange, the 64-bit client is working fine here. Of course it
may be that there is some subtle difference between Intel's em64t and
amd64.

In any case, there are some minor fixes involving truncated integers
(64-bit values copied or compared to a 32-bit integer). You should be
able to tell if your tree got this patch because the same patch also
removed the unused SafeStrCpy and SafeStrCat function from
coda-src/util/util.c, which probably weren't safe on a 64-bit
system anyways so it was in a way good they were unused.

The clog fix, was a couple of lines in coda-src/venus/vproc_pioctl.c
around line 1420, the code assumed userspace was passing a long, where
it really was passing an unsigned 32-bit integer. As a result the secret
token and realm identifier got truncated.

A very important fix for 64-bit clients was in librvm, rds/rds_free.c
line 181, the code keeps a list of pointers of areas that need to be
released when a transaction is committed, the list was sized as N*4
instead of N*sizeof(void *).

These fixes allow a client to successfully authenticate against a Coda
server, and replace cached objects without crashing.

However, there are 2 more patches that are essential if your client
wants to also write to the Coda servers. The CML records were packed
incorrectly, and we failed to send any file data back to the servers.

I just double checked and all of these patches did make it to CVS.

Now I have not tried the 64-bit server, and I'm sure it has similar
problems. If you have to run a Coda server on a 64-bit machine, the best
way is probably to compile with the -m32 flag, but I don't know if that
would also imply that all libraries have to be rebuilt as well, which is
probably not worth all the hassle.

The client pretty much has to be 64-bit to be able to communicate with
the 64-bit Coda kernel module. The server doesn't have the kernel
dependency, so it actually should run fine as a 32-bit binary on a
64-bit kernel,

> I was wondering if it was possible that being on a network using ipv6 
> (clients and server have ipv6 mask&addrs removed (with ifconfig) though) 
> might be a problem but I can't figure out why it could be.

ipv6 is not used, but doesn't hurt either. My desktop/laptop and one of
the Coda servers actually have both ipv4 and ipv6 connectivity. Some
code already works fine on ipv6, for instance clog and auth2. However
venus and codasrv are very much tied to being able to use a single ipv4
address to identify each other. They explicitly bind to a v4 socket and
only ask for ipv4 addresses.

Not being able to test your client against testserver does make it
difficult. Is there a reason why UDP is completely blocked? Are they as
strict with tcp connections?

Jan