Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r27880 - trunk/ompi/request

[George Bosilca]

Takahiro,

I went over this ticket and attached a new patch. Basically I went over all the 
possible cases, both in test and wait, and ensure the behavior is always 
consistent. Please give it a try, and let us know of the outcome.

  Thanks,
George.



On Jan 25, 2013, at 00:53 , "Kawashima, Takahiro"  
wrote:

> Jeff,
> 
> I've filed the ticket.
> https://svn.open-mpi.org/trac/ompi/ticket/3475
> 
> Thanks,
> Takahiro Kawashima,
> MPI development team,
> Fujitsu
> 
>> Many thanks for the summary!
>> 
>> Can you file tickets about this stuff against 1.7?  Included your patches, 
>> etc. 
>> 
>> These are pretty obscure issues and I'm ok not fixing them in the 1.6 branch 
>> (unless someone has a burning desire to get them fixed in 1.6). 
>> 
>> But we should properly track and fix these in the 1.7 series. I'd mark them 
>> as "critical" so that they don't get lost in the wilderness of other bugs. 
>> 
>> Sent from my phone. No type good. 
>> 
>> On Jan 22, 2013, at 8:57 PM, "Kawashima, Takahiro" 
>>  wrote:
>> 
>>> George,
>>> 
>>> I reported the bug three months ago.
>>> Your commit r27880 resolved one of the bugs reported by me,
>>> in another approach.
>>> 
>>> http://www.open-mpi.org/community/lists/devel/2012/10/11555.php
>>> 
>>> But other bugs are still open.
>>> 
>>> "(1) MPI_SOURCE of MPI_Status for a null request must be MPI_ANY_SOURCE."
>>> in my previous mail is not fixed yet. This can be fixed by my patch
>>> (ompi/mpi/c/wait.c and ompi/request/request.c part only) attached
>>> in my another mail.
>>> 
>>> http://www.open-mpi.org/community/lists/devel/2012/10/11561.php
>>> 
>>> "(2) MPI_Status for an inactive request must be an empty status."
>>> in my previous mail is partially fixed. MPI_Wait is fixed by your
>>> r27880. But MPI_Waitall and MPI_Testall should be fixed.
>>> Codes similar to your r27880 should be inserted to
>>> ompi_request_default_wait_all and ompi_request_default_test_all.
>>> 
>>> You can confirm the fixes by the test program status.c attached in
>>> my previous mail. Run with -n 2. 
>>> 
>>> http://www.open-mpi.org/community/lists/devel/2012/10/11555.php
>>> 
>>> Regards,
>>> Takahiro Kawashima,
>>> MPI development team,
>>> Fujitsu
>>> 
 To be honest it was hanging in one of my repos for some time. If I'm not 
 mistaken it is somehow related to one active ticket (but I couldn't find 
 the info). It might be good to push it upstream.
 
 George.
 
 On Jan 22, 2013, at 16:27 , "Jeff Squyres (jsquyres)"  
 wrote:
 
> George --
> 
> Is there any reason not to CMR this to v1.6 and v1.7?
> 
> 
> On Jan 21, 2013, at 6:35 AM, svn-commit-mai...@open-mpi.org wrote:
> 
>> Author: bosilca (George Bosilca)
>> Date: 2013-01-21 06:35:42 EST (Mon, 21 Jan 2013)
>> New Revision: 27880
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/27880
>> 
>> Log:
>> My understanding is that an MPI_WAIT() on an inactive request should
>> return the empty status (MPI 3.0 page 52 line 46).
>> 
>> Text files modified: 
>> trunk/ompi/request/req_wait.c | 3 +++
>>  
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>> 
>> Modified: trunk/ompi/request/req_wait.c
>> ==
>> --- trunk/ompi/request/req_wait.cSat Jan 19 19:33:42 2013(r27879)
>> +++ trunk/ompi/request/req_wait.c2013-01-21 06:35:42 EST (Mon, 21 
>> Jan 2013)(r27880)
>> @@ -61,6 +61,9 @@
>>  }
>>  if( req->req_persistent ) {
>>  if( req->req_state == OMPI_REQUEST_INACTIVE ) {
>> +if (MPI_STATUS_IGNORE != status) {
>> +*status = ompi_status_empty;
>> +}
>>  return OMPI_SUCCESS;
>>  }
>>  req->req_state = OMPI_REQUEST_INACTIVE;
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] June OMPI developer's meeting

[Larry Baker]

Jeff,

I would like to try to get down there (from Menlo Park) to meet and thank the 
OpenMPI developers, but I doubt I would be a very useful participant.  Will 
there be a social event that I could attend?  Maybe there is one at the MPI 
Forum?  Because of the US budget sequestration, I cannot spend any money, 
unless I do it on my own (in which case I have to bend over backwards to 
obscure my government affiliation -- like no mention of USGS on my registration 
or name badge).

Thanks,

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



On 30 Apr 2013, at 2:58 PM, Jeff Squyres (jsquyres) wrote:

> We are having a developer's meeting right before the MPI Forum meeting in 
> June, 2013.  All are welcome to attend.  Two primary topics for this meeting 
> will be: a) progress since the UTK meeting on moving the BTLs down to OPAL, 
> and b) asynchronous progress.
> 
> *** PLEASE SIGN UP ON THE WIKI PAGE SO THAT I CAN GET YOU A VISITOR'S BADGE 
> AND WIFI ***
> 
> Here's the wiki page:
> 
>https://svn.open-mpi.org/trac/ompi/wiki/Jun13Meeting
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r28418 - trunk/ompi/mca/vprotocol/base

[Ralph Castain]

On Apr 30, 2013, at 9:41 AM, George Bosilca  wrote:

> Ralph,
> 
> The log message is plain wrong. There is nothing non standard compliant in 
> the way the PML V is using the output, it is just it use an internal storage 
> for it's stream.

My point was that vprotocol isn't a standalone framework like all the others we 
have - it is tightly coupled to the pml/v component. That isn't the standard 
way we do things, as you know. The arrangement has caused some issues in the 
past, and this was just one that bit Nathan as he didn't realize it.

> 
> It should be straightforward to fix it by removing __ALL__ references to the 
> output variable not only the one from the structure.

Yes, but that then requires that the pml/v component directly reference the 
vprotocol framework object, which seems equally ugly. If that's what you want, 
then please feel free to do so - in which case, you could have just fixed it 
the way you want yourself :-)


> 
>  George.
> 
> 
> On Apr 30, 2013, at 18:37 , svn-commit-mai...@open-mpi.org wrote:
> 
>> Author: rhc (Ralph Castain)
>> Date: 2013-04-30 12:37:17 EDT (Tue, 30 Apr 2013)
>> New Revision: 28418
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/28418
>> 
>> Log:
>> Revert r28417 - given the non-standard way vprotocol is implemented, I see 
>> no way to use the framework verbosity here. Best to just leave it alone as 
>> those who use it know what they need to do to get debug output
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] [OMPI svn] svn:open-mpi r28417 - trunk/ompi/mca/vprotocol/base

[George Bosilca]

This commit broke the trunk.

  George.

On Apr 30, 2013, at 17:21 , svn-commit-mai...@open-mpi.org wrote:

> Author: hjelmn (Nathan Hjelm)
> Date: 2013-04-30 11:21:42 EDT (Tue, 30 Apr 2013)
> New Revision: 28417
> URL: https://svn.open-mpi.org/trac/ompi/changeset/28417
> 
> Log:
> vprotocol: remove the old output and use the framework output
> 
> Text files modified: 
>   trunk/ompi/mca/vprotocol/base/base.h  | 1 - 
>   
>   trunk/ompi/mca/vprotocol/base/vprotocol_base_select.c | 2 +-
>   
>   2 files changed, 1 insertions(+), 2 deletions(-)
> 
> Modified: trunk/ompi/mca/vprotocol/base/base.h
> ==
> --- trunk/ompi/mca/vprotocol/base/base.h  Tue Apr 30 06:10:23 2013
> (r28416)
> +++ trunk/ompi/mca/vprotocol/base/base.h  2013-04-30 11:21:42 EDT (Tue, 
> 30 Apr 2013)  (r28417)
> @@ -21,7 +21,6 @@
> BEGIN_C_DECLS
> 
> struct mca_pml_v_t {
> -int output;
> size_t  host_pml_req_recv_size;
> size_t  host_pml_req_send_size;
> mca_pml_base_component_thost_pml_component;
> 
> Modified: trunk/ompi/mca/vprotocol/base/vprotocol_base_select.c
> ==
> --- trunk/ompi/mca/vprotocol/base/vprotocol_base_select.c Tue Apr 30 
> 06:10:23 2013(r28416)
> +++ trunk/ompi/mca/vprotocol/base/vprotocol_base_select.c 2013-04-30 
> 11:21:42 EDT (Tue, 30 Apr 2013)  (r28417)
> @@ -124,7 +124,7 @@
> free(om);
> }
> 
> -mca_base_components_close(mca_pml_v.output, 
> +mca_base_components_close(ompi_vprotocol_base_framework.framework_output,
>   
> _vprotocol_base_framework.framework_components, 
>   (mca_base_component_t *) best_component);
> 
> ___
> svn mailing list
> s...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn

Re: [OMPI devel] Debug output issues on the trunk

[Jeff Squyres (jsquyres)]

...I see Nathan raising his hand...

:-)

Is there a way we can get opal_output / OPAL_OUTPUT to give us some help when 
this happens?  E.g., output a warning that it's been given an invalid stream 
ID?  I know we declare -1 as a valid output (effectively to the bitbucket); is 
there a unique way to identify these not-updated streams vs. legitimately--1 
(i.e., disabled) streams?


On Apr 29, 2013, at 10:33 PM, Ralph Castain  wrote:

> Hi folks
> 
> I've been encountering problems where setting "verbosity" values doesn't 
> result in any output. I finally tracked it down the not-too-recent overhaul 
> of the MCA parameter system. At that time, the mca_component_open function 
> was replaced with a framework_open function, and the "verbose_output" 
> parameter was removed in favor of a default framework_output variable that 
> exists in the framework object itself.
> 
> Unfortunately, when the change was made, the original verbose output 
> variables (in many places) were not removed. Thus, everything compiles - but 
> the verbosity parameter for that framework has no effect. I've now 
> found/fixed four frameworks where this occurred - after wasting a ton of time 
> and frustration :-(
> 
> So if you are trying to get debug output in a debug build, and setting a 
> verbosity yields no output, check the opal_output_verbose and 
> OPAL_OUTPUT_VERBOSE calls to ensure they are looking at the framework_output 
> channel and not the old one. Quite likely, it wasn't updated.
> 
> Meantime, I'm hoping to enlist help in slowly trolling thru all the 
> frameworks and components to correct the situation. Volunteers are 
> appreciated as this is going to take some time to fix.
> 
> Ralph
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] hwloc-1.7 issues

[Pavan Balaji]

On 04/30/2013 02:22 AM US Central Time, Brice Goglin wrote:
> Le 29/04/2013 15:51, Pavan Balaji a écrit :
>> On 04/29/2013 08:36 AM US Central Time, Brice Goglin wrote:
 I wonder if this CFLAGS=-D_POSIX_SOURCE is supported by FreeBSD headers.
>>> I could not fix this. Google says that FreeBSD does not define u_int
>>> when _POSIX_SOURCE, so the sysctl() prototype cannot be correct. I tend
>>> to think you should remove _POSIX_SOURCE on this FreeBSD release.
>> Is this for any version of POSIX_SOURCE?  Just giving _POSIX_SOURCE
>> falls back to POSIX.1-1990.  Most times we (mpich) only care about
>> POSIX.1-2001 (given by -D_POSIX_C_SOURCE=200112L).
>>
> 
> It seems to fail the same on FreeBSD 9.1 with -D_POSIX_C_SOURCE=200112L
> 
> By the way, regarding the AM_CONDITIONAL issue, you should remove the
> relevant "if" section from src/Makefile.am for now. You likely don't
> want to use plugins anyway? I still don't have a complete solution,
> there will be another mail later to discuss this.

Yes, this is what I've been doing to move things forward, but this is
not a great solution.

 -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji

Re: [hwloc-devel] hwloc-1.7 issues

[Brice Goglin]

Le 29/04/2013 15:51, Pavan Balaji a écrit :
> On 04/29/2013 08:36 AM US Central Time, Brice Goglin wrote:
>>> I wonder if this CFLAGS=-D_POSIX_SOURCE is supported by FreeBSD headers.
>> I could not fix this. Google says that FreeBSD does not define u_int
>> when _POSIX_SOURCE, so the sysctl() prototype cannot be correct. I tend
>> to think you should remove _POSIX_SOURCE on this FreeBSD release.
> Is this for any version of POSIX_SOURCE?  Just giving _POSIX_SOURCE
> falls back to POSIX.1-1990.  Most times we (mpich) only care about
> POSIX.1-2001 (given by -D_POSIX_C_SOURCE=200112L).
>

It seems to fail the same on FreeBSD 9.1 with -D_POSIX_C_SOURCE=200112L

By the way, regarding the AM_CONDITIONAL issue, you should remove the
relevant "if" section from src/Makefile.am for now. You likely don't
want to use plugins anyway? I still don't have a complete solution,
there will be another mail later to discuss this.

Brice