openmpi

Ralph Castain 7bee71aa59 Fix a potential, albeit perhaps esoteric, race condition that can occur for fast HNP's, slow orteds, and fast apps. Under those conditions, it is possible for the orted to be caught in its original send of contact info back to the HNP, and thus for the progress stack never to recover back to a high level. In those circumstances, the orted can "hang" when trying to exit.

Add a new function to opal_progress that tells us our recursion depth to support that solution.

Yes, I know this sounds picky, but good ol' Jeff managed to make it happen by driving his cluster near to death...

Also ensure that we declare "failed" for the daemon job when daemons fail instead of the application job. This is important so that orte knows that it cannot use xcast to tell daemons to "exit", nor should it expect all daemons to respond. Otherwise, it is possible to hang.

After lots of testing, decide to default (again) to slurm detecting failed orteds. This proved necessary to avoid rather annoying hangs that were difficult to recover from. There are conditions where slurm will fail to launch all daemons (slurm folks are working on it), and yet again, good ol' Jeff managed to find both of them.

Thanks you Jeff! :-/

This commit was SVN r18611.

2008-06-06 19:36:27 +00:00

help-opal-runtime.txt

Remove some old references to ft_enable parameter that no longer exists.

2007-03-17 20:02:42 +00:00

Makefile.am

Merging in the jjhursey-ft-cr-stable branch (r13912 : HEAD).

2007-03-16 23:11:45 +00:00

opal_cr.c

Some small fixes.

2008-05-29 15:05:28 +00:00

opal_cr.h

Some checkpoint/restart cleanup.