No bad news this time.
I grabbed the latest free versions of Open64 and PathScale and gave them
a try:
PASS:
linux/x86-64 w/ Open64-4.5.1 compilers from AMD
linux/x86-64 w/ ekopath-4.0.12.1 compilers from PathScale
Where "PASS" is my usual "make all install check".
-Paul
On 1/19/2012 9:
On 1/27/2012 5:24 AM, Jeff Squyres wrote:
On Jan 27, 2012, at 12:45 AM, Paul H. Hargrove wrote:
On this cluster, statfs() is returning ENOENT, which is breaking
opal_path_nfs().
So, these results are with test/opal/util/opal_path_nfs.c "disabled".
Paul -- can you explain this a little more?
On Fri, Jan 27, 2012 at 5:34 AM, Jeff Squyres wrote:
[snip]
>
>
> I'm not quite sure how that can happen -- orte_odls appears to be
> prototyped properly in orte/mca/odls/odls.h (i.e., it has ORTE_DECLSPEC,
> for visibility), and is properly instantiated in
> orte/mca/odls/base/odls_base_open.c.
>
Hi,
If a job is launched using "srun --resv-ports --cpu_bind:..." and slurm
is configured with:
TaskPlugin=task/affinity
TaskPluginParam=Cpusets
each rank of that job is in a cpuset that contains a single CPU.
Now, if we use carto on top of this, the following happens in
get_ib_dev_distanc
Hugo,
It seems you want to implement some sort of remote pessimistic logging -a la
MPICH-V1- ?
MPICH-V: Toward a Scalable Fault Tolerant MPI for Volatile Nodes -- George
Bosilca, Aurélien Bouteiller, Franck Cappello, Samir Djilali, Gilles Fédak,
Cécile Germain, Thomas Hérault, Pierre Lemarini
Hello Aurélien.
Thanks for the clarification. Considering what you've mentioned i will have
to make some adaptations, because to me, every single message has to be
logged. So, a sender not only will be sending messages to the receiver, but
also to an event logger. Is there any considerations that
Hugo,
Your program does not have non-deterministic events. Therefore, there are no
events to log. If you add MPI_ANY_SOURCE, you should see this code being
called. Please contact me again if you need more help.
Aurelien
Le 27 janv. 2012 à 10:21, Hugo Daniel Meyer a écrit :
> Hello @ll.
>
>
Hello @ll.
George, i'm using some pieces of the pessimist vprotocol. I've observed
that when you do a send, you call vprotocol_receiver_event_flush and here
the macro *__VPROTOCOL_RECEIVER_SEND_BUFFER* is called. I've noticed that
here you try send a copy of the message to process 0 using the el_c
On Jan 26, 2012, at 8:54 PM, Paul Hargrove wrote:
> libtool: link: pgcc -O -DNDEBUG -o orte-clean orte-clean.o
> ../../../orte/.libs/libopen-rte.a
> /Users/paul/openmpi-1.4.5rc2/BLD-pgi-11.10/opal/.libs/libopen-pal.a -lutil
> Undefined symbols for architecture x86_64:
> "_orte_odls", referenc
On Jan 27, 2012, at 12:45 AM, Paul H. Hargrove wrote:
> On this cluster, statfs() is returning ENOENT, which is breaking
> opal_path_nfs().
> So, these results are with test/opal/util/opal_path_nfs.c "disabled".
Paul -- can you explain this a little more? There should be logic in there to
effe
More positive results, with a caveat.
On this cluster, statfs() is returning ENOENT, which is breaking
opal_path_nfs().
So, these results are with test/opal/util/opal_path_nfs.c "disabled".
PASS (defined as "make all install check")
Linux/ppc32 with xlc-11.1 and xlf-13.1 compilers
Linux/
11 matches
Mail list logo