Hi Greg,

Please see embedded comments.

On 4/25/06, Greg Troxel <[EMAIL PROTECTED]> wrote:
Hmm.  I would think, given that you're running a 32-bit kernel
(presumably you are running the SUN4U kernel from NetBSD/sparc and
NetBSD/sparc userland) that you essentially see the same behavior as
on NetBSD/sparc.  I've run venus on that platform, but not codasrv.


This is yes, the NetBSD/sparc 3.0 userland sets plus, I took the GENERIC_SUN4U
kernel from NetBSD/sparc, patched it to fix DEFPA FDDI on SPARC, and rebuilt it.


I would guess you installed most dependencies from pkgsrc, and then
compiled lwp/rpc2/rvm/coda.  Is that right?


I actually installed everything manually -- downloaded source packages of gnu make
3.80, autoconf 2.59, automake 1.9.6, libtool 1.5.8, readline 5.1, m4 1.4. did the usual
./configure;make;make install routine for well-behaved programs. everything built fine
with no errors & i've used the tools to build other software packages e.g. SSH, BIND,
Apache

I then compiled lwp 2.1, rvm 1.11, and rpc2 1.28 from source as well using the same
./configure;make;make install methodology -- no show stopping errors, no wierd flags
passed to configure.


It could be that your problem is not because of using sparc.


I hope so! I run into some wierd snags with my SPARC machines that x86 users
probably don't heave to deal with, so to not have it be an architecture-specific issue
for once would be always refreshing. :)

In gdb, after attaching, do "bt" to get a stack backtrace.  Then do
"up" to move to where the signal was, and there "i frame" and "list".


Done! Here's the data:

(gdb) bt
#0  0x403bc3a0 in sleep () from /usr/local/lib/libc.so.12
#1  0x0008f2a8 in coda_assert (
    pred=0xf9e <Error reading address 0xf9e: Invalid argument>,
    file=0x94518 "srv.cc", line=302) at coda_assert.c:46
#2  0x00013c64 in zombie(int) (sig=3998) at srv.cc:302
#3  <signal handler called>

(gdb) up
#1  0x0008f2a8 in coda_assert (
    pred=0xf9e <Error reading address 0xf9e: Invalid argument>,
    file=0x94518 "srv.cc", line=302) at coda_assert.c:46
46                   sleep(1);
Current language:  auto; currently c

(gdb) i frame
Stack level 1, frame at 0xffffc250:
 pc = 0x8f2a8 in coda_assert (coda_assert.c:46); saved pc 0x13c64
 called by frame at 0xffffc2f8, caller of frame at 0xffffc1e8
 source language c.
 Arglist at 0xffffc250, args:
    pred=0xf9e <Error reading address 0xf9e: Invalid argument>,
    file=0x94518 "srv.cc", line=302
 Locals at 0xffffc250, Previous frame's sp in sp

(gdb) list
41          case CODA_ASSERT_SLEEP:
42              fprintf(stderr, "Sleeping forever.  You may use gdb to attach to process %d.",
43                      (int)getpid());
44              fflush(stderr);
45              for (;;)
46                   sleep(1);
47              break;
48     
49          case CODA_ASSERT_EXIT:
50              fprintf(stderr, "EXITING! Bye!\n");
(gdb)


I have made some fixes in NetBSD current for coda kernel support that
have not yet been applied to 3.0.  But that affects system stability
with venus, not running codasrv.

This is where I was *really* expecting problems to occur -- on the client end
rather than the server end. I built new kernels with the coda driver config'd in
and they boot up okay, but I was expecting finicky behaviour once I actually
started to use the coda client -- file-system CODA is not by default enabled
in /sparc and /sparc64 kernel configuration files in NetBSD so I assumed it
was perhaps "a little sketchy" and thus I expect some strange behaviour
perhaps.

Unfortunately I wasn't even able to get that far since I have no servers up and
running to test! Arg... If I can manage to get codasrv starting up on my servers,
I might keep those client patches in the back of my mind :)
 

I use the following for building from CVS.  I use gmake, but I don't
remember why make didn't work.  That's probably not your problem.

#!/bin/sh
for i in lwp rpc2 rvm coda; do
  echo "BUILDING $i" && \
  (cd $i && \
  ./bootstrap.sh && \
  rm -f config.cache && \
  LDFLAGS="-L/usr/pkg/lib -R/usr/pkg/lib" CPPFLAGS="-I/usr/pkg/include" ./configure --prefix=/usr/local/coda && \
  gmake -k clean &&
  gmake -k &&
  gmake install)
done
(cd coda && gmake -k client-install server-install)
exit 0


Never ran into any make errors using gmake. I think using BSD make
instead gives "missing seperator" errors or some other syntax-y thing.

I just ln -s /usr/lib /usr/local/lib; ln -s /usr/include /usr/local/include to
put any silliness about lost libs or includes to rest; besides, didn't get
any of the usual errors associated with bad libs or headers such as
compilation errors or successful build but undefined symbol on run...

--
        Greg Troxel <[EMAIL PROTECTED]>

Thanks for the response thus far.

Regards, Sean
[EMAIL PROTECTED]

Reply via email to