Ralph's commit fixed both usnic and sm.
Thanks!
On Jul 28, 2014, at 2:36 PM, Jeff Squyres (jsquyres) wrote:
> On Jul 28, 2014, at 2:23 PM, George Bosilca wrote:
>
>> Patience ...
>
> No worries; we knew stuff like this would happen after the initial merge.
>
> Thanks for digging in to it.
Working on it now...
On Jul 28, 2014, at 11:36 AM, Jeff Squyres (jsquyres)
wrote:
> On Jul 28, 2014, at 2:23 PM, George Bosilca wrote:
>
>> Patience ...
>
> No worries; we knew stuff like this would happen after the initial merge.
>
> Thanks for digging in to it.
>
> --
> Jeff Squyres
> j
On Jul 28, 2014, at 2:23 PM, George Bosilca wrote:
> Patience ...
No worries; we knew stuff like this would happen after the initial merge.
Thanks for digging in to it.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/leg
Ignore my previous email, I see what is going on. Basically, there are 6
data made available to the BTL: nodename, job_session_dir,
proc_session_dir, num_local_peers, my_local_rank and if available cpuset.
Some of this information is available early in the startup while others are
only available a
Well, I'm slightly confused as the BTL are initialized outside opal_init.
There must be a specific call to mca_base_framework_open for the BTL, and
currently this call is made in the BML. As the BML is only initialized once
the RTE is up, I don't understand how do you get the "not initialized".
I'd be ok with that.
George?
On Jul 28, 2014, at 1:20 PM, Ralph Castain wrote:
> I think we should not have opal_init setup the BTLs at all. Let's leave that
> for the RTE setup to do as it can control the sequencing to ensure all the
> data is available and ready
>
> On Jul 28, 2014, at 10
I think we should not have opal_init setup the BTLs at all. Let's leave that
for the RTE setup to do as it can control the sequencing to ensure all the data
is available and ready
On Jul 28, 2014, at 10:21 AM, Jeff Squyres (jsquyres)
wrote:
> Well, this is a pickle.
>
> I'm setting up compon
Well, this is a pickle.
I'm setting up component-wide resources in the BTL component init. I am doing
this because the creation of the modules that I return from BTL component init
(currently) *assume* that all of these component resources are already setup.
If I have to defer setting up compo
This means you are trying to initialize things too early. Most of the
information made available in opal/util/proc.h is only available once the
RTE was setup, i.e. only after the call to rte_init. Thus, the BTL can only
use it after the init call...
George.
On Mon, Jul 28, 2014 at 1:01 PM, Ra
On Jul 28, 2014, at 9:57 AM, Jeff Squyres (jsquyres) wrote:
> I'm getting a value of "not yet defined" for
> opal_process_info.job_session_dir in the usnic BTL (is this also what is
> happening for
> http://www.open-mpi.org/community/lists/devel/2014/07/15276.php?).
>
> Can the job_session_d
I'm getting a value of "not yet defined" for opal_process_info.job_session_dir
in the usnic BTL (is this also what is happening for
http://www.open-mpi.org/community/lists/devel/2014/07/15276.php?).
Can the job_session_dir be define/setup before the BTLs are setup?
--
Jeff Squyres
jsquy...@cis
11 matches
Mail list logo
