On Sep 12, 2012, at 4:45 PM, Paul Hargrove wrote:
> Sounds like that should resolve my failure - I'll try to verify from a
> nightly tarball when I have the opportunity.
Thanks! I'll probably make another RC this afternoon, because we're really
closing in on it.
> The fix I had in mind would
Sounds like that should resolve my failure - I'll try to verify from a
nightly tarball when I have the opportunity.
The fix I had in mind would have been to parse the mounts with sufficient
intelligence to match a bind-mount to the original mount and determine it's
type.
I suppose that is still po
I just updated the test to check and see if we get a "none" type of filesystem.
If so, we just skip it in the test.
On Sep 11, 2012, at 3:50 PM, Paul Hargrove wrote:
> I am NOT running on BG/Q.
> I am just building for Linux/PPC64 on its front-end node which has very
> recent XLC versions ins
I am NOT running on BG/Q.
I am just building for Linux/PPC64 on its front-end node which has very
recent XLC versions installed.
I did look quickly just now at the opal_path_nfs.c test code and see that
get_mounts() will require non-trivial work to process bind-mounts. The
work is "just a matter
Interesting - I can certainly fix the test so it lets make check complete.
FWIW: I didn't know we were running on BG/Q - does it work? I assume this is
with slurm?
On Sep 11, 2012, at 12:34 PM, Paul Hargrove wrote:
> In testing 1.6.2rc2 on a BG/Q front-end I've encountered the following
> fai
In testing 1.6.2rc2 on a BG/Q front-end I've encountered the following
failure from "make check":
Failure : Mismatch: input "/soft", expected:0 got:1
> SUPPORT: OMPI Test failed: opal_path_nfs() (1 of 20 failed)
> FAIL: opal_path_nfs
What I find digging deeper is that the mount of /soft is a bi
