Greetings,
I'm running the Debian package of OpenMPI in a chroot (with /proc
mounted properly), and orte_init is failing as follows:
$ uptime
12:51:55 up 12 days, 21:30, 0 users, load average: 0.00, 0.00, 0.00
$ orterun -np 1 uptime
[new-host-3:18250] [0,0,0] ORTE_ERROR_LOG: Error in file
run
Adam C Powell IV wrote:
Greetings,
I'm running the Debian package of OpenMPI in a chroot (with /proc
mounted properly), and orte_init is failing as follows:
$ uptime
12:51:55 up 12 days, 21:30, 0 users, load average: 0.00, 0.00, 0.00
$ orterun -np 1 uptime
[new-host-3:18250] [0,0,0] ORTE_ERR
On Wed, 2007-07-18 at 09:50 -0400, Tim Prins wrote:
> Adam C Powell IV wrote:
> > Greetings,
> >
> > I'm running the Debian package of OpenMPI in a chroot (with /proc
> > mounted properly), and orte_init is failing as follows:
> > [snip]
> > What could be wrong? Does orterun not run in a chroot e
This is strange. I assume that you what to use rsh or ssh to launch the
processes?
If you want to use ssh, does "which ssh" find ssh? Similarly, if you
want to use rsh, does "which rsh" find rsh?
Thanks,
Tim
Adam C Powell IV wrote:
On Wed, 2007-07-18 at 09:50 -0400, Tim Prins wrote:
Adam
MPITB is an Octave toolbox for MPI. The new release also works with
Open-MPI. Test reports are welcome, since this is an initial release.
For more information see http://atc.ugr.es/javier-bin/mpitb
Thanks
-javier
On Tue, Jul 10, 2007 at 04:36:01PM +, jody wrote:
> I think there is still some problem.
> I create different datatypes by resizing MPI_SHORT with
> different negative lower bounds (depending on the rank)
> and the same extent (only depending on the number of processes).
>
> However, I get an
As mentioned, I'm running in a chroot environment, so rsh and ssh won't
work: "rsh localhost" will rsh into the primary local host environment,
not the chroot, which will fail.
[The purpose is to be able to build and test MPI programs in the Debian
unstable distribution, without upgrading the whol
On 7/18/07 9:49 AM, "Adam C Powell IV" wrote:
> As mentioned, I'm running in a chroot environment, so rsh and ssh won't
> work: "rsh localhost" will rsh into the primary local host environment,
> not the chroot, which will fail.
>
> [The purpose is to be able to build and test MPI programs in
Adam C Powell IV wrote:
As mentioned, I'm running in a chroot environment, so rsh and ssh won't
work: "rsh localhost" will rsh into the primary local host environment,
not the chroot, which will fail.
[The purpose is to be able to build and test MPI programs in the Debian
unstable distribution,
--- Ralph Castain wrote:
> No, the session directory is created in the tmpdir - we don't create
> anything anywhere else, nor do we write any executables anywhere.
In the case where the TMPDIR env variable isn't specified, what is the
default assumed by Open MPI/orte?
> Just out of curiosity: a
Tim has proposed a clever fix that I had not thought of - just be aware that
it could cause unexpected behavior at some point. Still, for what you are
trying to do, that might meet your needs.
Ralph
On 7/18/07 11:44 AM, "Tim Prins" wrote:
> Adam C Powell IV wrote:
>> As mentioned, I'm running
On 7/18/07 11:46 AM, "Bill Johnstone" wrote:
> --- Ralph Castain wrote:
>
>> No, the session directory is created in the tmpdir - we don't create
>> anything anywhere else, nor do we write any executables anywhere.
>
> In the case where the TMPDIR env variable isn't specified, what is the
>
--- Ralph Castain wrote:
> Unfortunately, we don't have more debug statements internal to that
> function. I'll have to create a patch for you that will add some so
> we can
> better understand why it is failing - will try to send it to you on
> Wed.
Thank you for the patch you sent.
I solved
On Wed, 2007-07-18 at 13:44 -0400, Tim Prins wrote:
> Adam C Powell IV wrote:
> > As mentioned, I'm running in a chroot environment, so rsh and ssh won't
> > work: "rsh localhost" will rsh into the primary local host environment,
> > not the chroot, which will fail.
> >
> > [The purpose is to be a
Hooray! Glad we could help track this down - sorry it was so hard to do so.
To answer your questions:
1. Yes - ORTE should bail out gracefully. It definitely should not hang. I
will log the problem and investigate. I believe I know where the problem
lies, and it may already be fixed on our trunk,
> Yes, this helps tremendously. I installed rsh, and now it pretty much
> works.
Glad this worked out for you.
>
> The one missing detail is that I can't seem to get the stdout/stderr
> output. For example:
>
> $ orterun -np 1 uptime
> $ uptime
> 18:24:27 up 13 days, 3:03, 0 users, load aver
Brian,
To close this one off, we found that one of our libraries has a
malloc/free that was being called from ompi. I should have looked at
the crash reporter. It reported
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x05801bfc
Thread 0 Crashed:
0 lib
Hi Tim,
Thanks for the follow-up
On 18 July 2007 at 17:22, Tim Prins wrote:
|
| > Yes, this helps tremendously. I installed rsh, and now it pretty much
| > works.
| Glad this worked out for you.
|
| >
| > The one missing detail is that I can't seem to get the stdout/stderr
| > output. For ex
18 matches
Mail list logo
