On Jan 27, 2014, at 1:24 PM, Nathan Hjelm wrote:
> On Mon, Jan 27, 2014 at 01:10:43PM -0800, Ralph Castain wrote:
>> Nathan, I have no idea what you are talking about. What I do know is that
>> you had me commit a patch to the trunk and v1.7.4 that caused multiple
>> warnings about 32-bit issu
On Mon, Jan 27, 2014 at 01:10:43PM -0800, Ralph Castain wrote:
> Nathan, I have no idea what you are talking about. What I do know is that you
> had me commit a patch to the trunk and v1.7.4 that caused multiple warnings
> about 32-bit issues to appear in both cases. George is reporting issues th
Nathan, I have no idea what you are talking about. What I do know is that you
had me commit a patch to the trunk and v1.7.4 that caused multiple warnings
about 32-bit issues to appear in both cases. George is reporting issues that
look very much like the ones I'd expect based on those warnings.
Nope. Vader will not work on non-xpmem systems in 1.7.4. The CMR is
still open for 1.7.5 (#4053. Issue like the one George reported are
why I chose to hold off on the new vader until 1.7.5.
The fix is complete. At this point I am waiting on some feedback on
changes to OMPI_CHECK_PACKAGE before com
Nathan,
To encourage you to focus on 1.7.4, I will delay testing vader on the SGI
UV until I've tested the next 1.7.4 release candidate (or final).
-Paul
On Mon, Jan 27, 2014 at 12:55 PM, Ralph Castain wrote:
> Just FWIW: I believe that problem did indeed make it over to 1.7.4, and
> that rel
Just FWIW: I believe that problem did indeed make it over to 1.7.4, and that
release is on "hold" pending your fix. So while I'm happy to hear about xpmem
on SGI, please do let us release 1.7.4!
On Jan 27, 2014, at 8:19 AM, Nathan Hjelm wrote:
> Yup. Has to do with not having 64-bit atomic ma
Yup. Has to do with not having 64-bit atomic math. The fix is complete
but I am working on another update to enable using xpmem on SGI
systems. I will push the changes once that is complete.
-Nathan
On Mon, Jan 27, 2014 at 04:00:08PM +, Jeff Squyres (jsquyres) wrote:
> Is this the same issue
Is this the same issue Absoft is seeing in 32 bit builds on the trunk? (i.e.,
100% failure rate)
http://mtt.open-mpi.org/index.php?do_redir=2142
On Jan 27, 2014, at 10:38 AM, Nathan Hjelm wrote:
> This shouldn't be affecting 1.7.4 since neither the vader or coll/ml
> updates have been mo
This shouldn't be affecting 1.7.4 since neither the vader or coll/ml
updates have been moved yet. As for trunk I am working on a 32-bit fix
for vader and it should be in later today. I will have to track down
what is going wrong the basesmuma initialization.
-Nathan
On Sun, Jan 26, 2014 at 04:10:
I noticed two major issues on 32 bits machines. The first one is with the vader
BTL and the second with the selection logic in basesmuma
(bcol_basesmuma_bank_init_opti). Both versions are impacted: trunk and 1.7.
If I turn off vader and boll via the MCA parameters everything runs just fine.
G
10 matches
Mail list logo
