(Illustration by Gaich Muramatsu)
Jan Harkes wrote: > 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. > I checked my sources, and it seems they are up-to-date. Just to be sure, I build from those sources again, and I get exactly the same behaviour. I naively tried to checkout where could be the problem :) I'm no expert in architecture specifics but I my first guess would be that rpc2 is truncating somewhere while binding to the server. in coda-src/auth2/auser.c TryBinding() always gets a 0 at the RPC2_Newbinding() call I checked rpc2/rpc2-src/rpc2a.c for RPC2_Newbinding() but there is no return statement (maybe normal?) I tried to study types and conversion, I didn't see anything wrong but there is a lot of code and depedencies. (hopefully many functions are clearly named & described, thank you !) > 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 think it might be worth the try (just to know if it solves the problem), but I think it might be a long work. > 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. > ok, thank you, I would have wasted time on that :) > 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? > UDP is simply droped in both ways because of the provider which is used & for QOS. it's rather extreme but they don't really care, because in the past some students abused (p2p...). Anyway, I guess I should try to find a 32bit computer to try the coda server, just to be sure I didn't messed up somewhere. -- Stephane CanceReceived on 2007-02-17 11:30:16