----- Original Message -----
From: [email protected]
<[email protected]>
To: [email protected] <[email protected]>
Sent: Thu Mar 12 13:00:04 2009
Subject: general Digest, Vol 26, Issue 73
Send general mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of general digest..."
Today's Topics:
1. Re: Re: [PATCH] infiniband-diags: Fix memory leaks on
IBERROR and IBPANIC (Hal Rosenstock)
2. RE: Re: [PATCH] infiniband-diags: Fix memory leaks on
IBERROR and IBPANIC (Sean Hefty)
3. Re: Re: [PATCH] infiniband-diags: Fix memory leaks on
IBERROR and IBPANIC (Hal Rosenstock)
4. Re: [PATCH] opensm/osm_ucast_ftree.c: remove __osm_ftree
prefix in static functions (Sasha Khapyorsky)
5. Re: [PATCH v2] opensm/osm_link_mgr.c initialize SMSL
(Sasha Khapyorsky)
6. ***SPAM*** Re: [ofa-general] Re: [PATCH] infiniband-diags:
Fix memory leaks on IBERROR and IBPANIC (Hal Rosenstock)
7. Re: [PATCH 1/2] opensm: Add common ib_gid_is_notzero routine
(Sasha Khapyorsky)
8. Re: ***SPAM*** Re: [ofa-general] Re: [PATCH]
infiniband-diags: Fix memory leaks on IBERROR and IBPANIC (Ira Weiny)
9. RE: ibdmchk: How to generate PSL and SL2VL files ? (Eitan Zahavi)
----------------------------------------------------------------------
Message: 1
Date: Thu, 12 Mar 2009 13:31:23 -0400
From: Hal Rosenstock <[email protected]>
Subject: Re: [ofa-general] Re: [PATCH] infiniband-diags: Fix memory
leaks on IBERROR and IBPANIC
To: Sasha Khapyorsky <[email protected]>
Cc: Hal Rosenstock <[email protected]>, [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 12, 2009 at 12:35 PM, Sasha Khapyorsky <[email protected]> wrote:
> On 11:55 Thu 12 Mar ?? ?? , Hal Rosenstock wrote:
>>
>> Since these macros exit, now need to call mad_rpc_close_port
>> prior to invoking them
>
> Both IBERROR and IBPANIC calls exit(), it closes all opened files. This
> patch looks like an overkill.
It's not a matter of relying on exit for open fds but rather the
allocated memory under the covers of mad_rpc_open_port so no longer
can one rely on just exit and this needs to be made explicit.
-- Hal
> Sasha
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
------------------------------
Message: 2
Date: Thu, 12 Mar 2009 10:35:58 -0700
From: "Sean Hefty" <[email protected]>
Subject: RE: [ofa-general] Re: [PATCH] infiniband-diags: Fix memory
leaks on IBERROR and IBPANIC
To: "'Hal Rosenstock'" <[email protected]>, "Sasha Khapyorsky"
<[email protected]>
Cc: Hal Rosenstock <[email protected]>, [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
>It's not a matter of relying on exit for open fds but rather the
>allocated memory under the covers of mad_rpc_open_port so no longer
>can one rely on just exit and this needs to be made explicit.
The OS should reclaim any allocated memory not freed by the app when it exits.
Is this your concern?
------------------------------
Message: 3
Date: Thu, 12 Mar 2009 13:45:22 -0400
From: Hal Rosenstock <[email protected]>
Subject: Re: [ofa-general] Re: [PATCH] infiniband-diags: Fix memory
leaks on IBERROR and IBPANIC
To: Sean Hefty <[email protected]>
Cc: Hal Rosenstock <[email protected]>, [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 12, 2009 at 1:35 PM, Sean Hefty <[email protected]> wrote:
>>It's not a matter of relying on exit for open fds but rather the
>>allocated memory under the covers of mad_rpc_open_port so no longer
>>can one rely on just exit and this needs to be made explicit.
>
> The OS should reclaim any allocated memory not freed by the app when it exits.
> Is this your concern?
malloc'd memory ?
------------------------------
Message: 4
Date: Thu, 12 Mar 2009 19:53:03 +0200
From: Sasha Khapyorsky <[email protected]>
Subject: [ofa-general] Re: [PATCH] opensm/osm_ucast_ftree.c: remove
__osm_ftree prefix in static functions
To: Yevgeny Kliteynik <[email protected]>
Cc: OpenIB <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On 11:30 Thu 12 Mar , Yevgeny Kliteynik wrote:
> Hi Sasha,
>
> Removing all the __osm_ftree prefixes in static functions naming.
>
> Signed-off-by: Yevgeny Kliteynik <[email protected]>
Applied. Thanks.
I also formatted osm_ucast_ftree.c with osm_indent.
Sasha
------------------------------
Message: 5
Date: Thu, 12 Mar 2009 20:07:48 +0200
From: Sasha Khapyorsky <[email protected]>
Subject: [ofa-general] Re: [PATCH v2] opensm/osm_link_mgr.c initialize
SMSL
To: [email protected]
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On 10:37 Tue 10 Mar , [email protected] wrote:
> The SMSL is currently not initialized. Whatever is written in PortInfo
> at power up is kept.
>
> The lash routing algorithm makes active use of SL to avoid deadlock in
> the fabric. The endnodes needs to be instructed to use the SL calculated
> for the endnode-to-SMnode path for SA traffic. If not, the SA traffic
> can cause deadlock.
>
> This change makes sure that the SMSL is properly initialized on all
> ports. If flash routing is used, the SMSL is set up based on routing
> calculations. For other routing algorithms the default SMSL is used.
>
>
> Signed-off-by: Line Holen <[email protected]>
Applied. Thanks.
Sasha
------------------------------
Message: 6
Date: Thu, 12 Mar 2009 14:05:09 -0400
From: Hal Rosenstock <[email protected]>
Subject: ***SPAM*** Re: [ofa-general] Re: [PATCH] infiniband-diags:
Fix memory leaks on IBERROR and IBPANIC
To: Sean Hefty <[email protected]>
Cc: Hal Rosenstock <[email protected]>, [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 12, 2009 at 1:45 PM, Hal Rosenstock
<[email protected]> wrote:
> On Thu, Mar 12, 2009 at 1:35 PM, Sean Hefty <[email protected]> wrote:
>>>It's not a matter of relying on exit for open fds but rather the
>>>allocated memory under the covers of mad_rpc_open_port so no longer
>>>can one rely on just exit and this needs to be made explicit.
>>
>> The OS should reclaim any allocated memory not freed by the app when it
>> exits.
>> Is this your concern?
>
> malloc'd memory ?
Many OSs do but not all. Should we rely on this ? Also, don't other
userspace programs attempt to properly cleanup after themselves rather
than rely on OS cleanup behavior ?
------------------------------
Message: 7
Date: Thu, 12 Mar 2009 20:19:51 +0200
From: Sasha Khapyorsky <[email protected]>
Subject: [ofa-general] Re: [PATCH 1/2] opensm: Add common
ib_gid_is_notzero routine
To: Hal Rosenstock <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On 14:22 Tue 10 Mar , Hal Rosenstock wrote:
>
> Signed-off-by: Hal Rosenstock <[email protected]>
> ---
> diff --git a/opensm/include/iba/ib_types.h b/opensm/include/iba/ib_types.h
> index e7cbb79..bfe8665 100644
> --- a/opensm/include/iba/ib_types.h
> +++ b/opensm/include/iba/ib_types.h
> @@ -2338,6 +2338,40 @@ ib_gid_get_guid(IN const ib_gid_t * const p_gid)
> * ib_gid_t
> *********/
>
> +OSM_EXPORT const ib_gid_t ib_zero_gid;
> +
> +/****f* IBA Base: Types/ib_gid_is_notzero
> +* NAME
> +* ib_gid_is_notzero
> +*
> +* DESCRIPTION
> +* Returns a boolean indicating whether or not the GID is zero.
> +*
> +* SYNOPSIS
> +*/
> +static inline boolean_t OSM_API
> +ib_gid_is_notzero(IN const ib_gid_t * const p_gid)
> +{
> + if (memcmp(p_gid, &ib_zero_gid, sizeof(*p_gid)))
> + return TRUE;
> + return FALSE;
> +}
[snip...]
> diff --git a/opensm/opensm/osm_helper.c b/opensm/opensm/osm_helper.c
> index c56f5b2..b40ba0c 100644
> --- a/opensm/opensm/osm_helper.c
> +++ b/opensm/opensm/osm_helper.c
> @@ -535,6 +535,8 @@ const char *ib_get_trap_str(ib_net16_t trap_num)
> return "Unknown";
> }
>
> +const ib_gid_t ib_zero_gid = {};
> +
This introduces dependency against libopensm for ib_types.h users.
I would suggest to put all this stuff to osm_helper.
Sasha
------------------------------
Message: 8
Date: Thu, 12 Mar 2009 11:23:07 -0700
From: Ira Weiny <[email protected]>
Subject: Re: ***SPAM*** Re: [ofa-general] Re: [PATCH]
infiniband-diags: Fix memory leaks on IBERROR and IBPANIC
To: Hal Rosenstock <[email protected]>
Cc: Hal Rosenstock <[email protected]>, [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII
On Thu, 12 Mar 2009 14:05:09 -0400
Hal Rosenstock <[email protected]> wrote:
> On Thu, Mar 12, 2009 at 1:45 PM, Hal Rosenstock
> <[email protected]> wrote:
> > On Thu, Mar 12, 2009 at 1:35 PM, Sean Hefty <[email protected]> wrote:
> >>>It's not a matter of relying on exit for open fds but rather the
> >>>allocated memory under the covers of mad_rpc_open_port so no longer
> >>>can one rely on just exit and this needs to be made explicit.
> >>
> >> The OS should reclaim any allocated memory not freed by the app when it
> >> exits.
> >> Is this your concern?
> >
> > malloc'd memory ?
>
> Many OSs do but not all. Should we rely on this ? Also, don't other
> userspace programs attempt to properly cleanup after themselves rather
> than rely on OS cleanup behavior ?
Strictly speaking I think Hal is right on this one. I should have made the
change myself was lazy.
Another more tangible reason for this is we may change the behavior of the
macros in the future. IBERROR recently fooled Sasha into thinking execution
continued. IBPANIC is perhaps a bit more clear that it will exit.
Ira
> _______________________________________________
> general mailing list
> [email protected]
> http:// lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit http://
> openib.org/mailman/listinfo/openib-general
>
--
Ira Weiny
Math Programer/Computer Scientist
Larence Livermore National Lab
[email protected]
------------------------------
Message: 9
Date: Thu, 12 Mar 2009 20:06:17 +0200
From: "Eitan Zahavi" <[email protected]>
Subject: [ofa-general] RE: ibdmchk: How to generate PSL and SL2VL
files ?
To: "Keshetti Mahesh" <[email protected]>
Cc: openIB <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Mahesh,
The help message is erroneous:
First these file are not mandatory.
Second OpenSM does not generate them.
The files can be generated by performing SA PathRecord queries.
We do not automation for that yet.
So it seems we need to perform 2 things:
1. Fix the help / man
2. Write some SA client code for obtaining the data.
Thanks for pointing this up.
Eitan Zahavi
Senior Engineering Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL
> -----Original Message-----
> From: Keshetti Mahesh [mailto:[email protected]]
> Sent: Thursday, March 12, 2009 8:27 AM
> To: Eitan Zahavi
> Cc: openIB
> Subject: Re: ibdmchk: How to generate PSL and SL2VL files ?
>
> On Thu, Mar 12, 2009 at 11:52 AM, Keshetti Mahesh
> <[email protected]> wrote:
> > Hi,
> >
> > Current implementation of 'ibdmchk' in cluster verification mode
> > requires path<->SL(PSL) and SL2VL files as input. And the help(-h)
> > message says that these files can be generated by OpenSM
> with '-D 0x43'.
> >
> > But I am not able to generate any such file with OpenSM. And there
> > isn't any information related to these files in man page as well as
> > help(-h). Can anyone please tell me how to generate
> path<->SL and SL2VL files using OpenSM?
> >
>
> I am using OpenSM of OFED-1.4 distribution.
>
> -Mahesh
>
------------------------------
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
End of general Digest, Vol 26, Issue 73
***************************************
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
