[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MPICH-1.2.0 on GNU/Debian (Alpha) 2.1


Shaun Cloherty <s.cloherty@gsbme.unsw.edu.au> writes:

> I'm trying to install mpich-1.2.0 on a  GNU/Debian (Alpha) 2.1
> Linux (2.2.12) box which mounts its filesystem via nfs. I
> configured the source tree using;
> # ./configure --with-device=ch_p4 --with-arch=LINUX_ALPHA --with-mpe -opt="-mcpu=ev4" --disable-f77 --disable-f90 -disable-devdebug -prefix=/usr/local/mpich-1.2.0
> which succeeds, but produces a couple of messages that concern me;
> :
> :
> Configuring p4 subsystem...
> checking for gcc... cc
> checking whether the C compiler (cc  ) works... yes
> checking whether the C compiler (cc  ) is a cross-compiler... no
> checking whether we are using GNU C... yes
> checking whether cc accepts -g... yes
> checking for mmap... yes
> checking that shared, anonymous mmap works with -1 filedes... no!
> checking that semget works... undetermined
> *# Could not compile program
> :
> :
> Could not compile program!? Can anyone shed some light on this,
> what is semget?? why might it be undetermined?? I'm running
> kernel 2.2.12.

Please let me prefrace this by saying that I've never used mpich, only lam.
Mark, could you comment here?

This might be due to your disabling of the fortran, no doubt because
of g77 difficulties on alpha.  (If you want a wrapper script which
calls f2c to step around g77 probs on alpha and which can be used as
F77 in make, look at the latest lapack package.)  configure seems to
be skipping a test here.  configure produces a log -- can you check
what it says at this point?  You can also look at the configure.in
script and see what test is being run to check semget.  semget is a
system call which retrieves a semaphore identifier.  Semaphores
provide the locking mecanism in SysV shared memory.  You'll most
likely only be using this if you have one or more dual processor (SMP)

> Later in the configure process, I see;
> :
> :
> Configuring the test suite...
> Configuring with args -basecc=cc
> -cc=/home/shaunc/mpich-1.2.0/bin/mpicc -nof77 -make=make
> --no-print-directory -mpichpath=/home/shaunc/mpich-1.2.0/bin
> Don't build the tests that need Fortran
> *# Unrecognized configure option
>   configuring for "LINUX_ALPHA" target architecture
> :
> :
> Humm... unrecognized configure option.....

Again, could you please check the log and configure.in script at this

> As I said, the configure completes ok, so I ran 'make', then
> 'make testing' (in the examples/test subdir). Here's where my
> problem begins, the tests start ok, but seem to take forever,
> printing;
> :
> :
> Making testing in directory pt2pt
> ./runtests -small
> **** Testing MPI Point-to-point routines ****
> SC-Cluster-10 : Tue Feb  1 08:42:11 /etc/localtime 2000
> /home/shaunc/mpich-1.2.0/bin/mpicc -DMPID_NO_FORTRAN
> -DHAVE_SIGNAL_H=1 -DHAVE_SIGACTION=1   -c sendrecv.c
> /home/shaunc/mpich-1.2.0/bin/mpicc  -o sendrecv sendrecv.o
> test.o
> **** Testing MPI_Send and MPI_Recv ****
> The machine then sits there for many hours after which time I get bored and hit Ctrl-C, 4 instances of
> 'sendrecv' are listed in the output from 'top', only two of which seem to be doing anything.

Do you have a cluster, or are you running mpich on just one box?  In
this case, you definitely need semaphores and sysv memory.  Your test
is obviously not just taking long, but failing, most probably waiting
forever for some transport mechanism (eg. tcp, sysv shared mem) to

> This is a 166MHz machine, so its not a rocket, but I would still expect the test suite to complete within a few hours, or at least progress past the first test. Any ideas anyone??
> Any suggestions greatly appreciated,

You should forward this to the mpich maintainer, Mark Brown, as he is
our expert!

> Shaun
> PS: yep, the filesystem is mounted 'noac'.
> --
> Shaun Cloherty
> Graduate School of Biomedical Engineering
> University of New South Wales
> --  
> To UNSUBSCRIBE, email to debian-beowulf-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: