More information,<br>
<br>
The test case is as follows<br>
<br>
1. Start opensm in verbose mode (-V)<br>
2. Ping remote node <br>
3. osmtest -f c<br>
4. osmtest -f a<br>
5. pkill -9 opensm<br>
6. Repeat over<br>
<br>
Out of about 2500 iterations, 143  osmtest  failed. Keep in
mind,  only Step 4 failed.  Step 3 which is inventory file
creation *never* failed. (I think inventory file creation also talks to
SA right ?)<br>
<br>
-Viswa<br>
<br>
<br><br><div><span class="gmail_quote">On 23 Sep 2005 12:54:56 -0400, <b class="gmail_sendername">Hal Rosenstock</b> <<a href="mailto:halr@voltaire.com">halr@voltaire.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Eitan,<br><br>On Fri, 2005-09-23 at 12:19, Eitan Zahavi wrote:<br>> Hi Hal, Viswa,<br>><br>> Sorry I'm joining late on this thread due to the weekend (which starts<br>> here on Friday ending Saturday night).
<br>> Is there any conclusion on this one?<br><br>No.<br><br>> The only log I have seen was from osmtest failing to send a MAD.<br><br>True.<br><br>> Looks like a umad issue?<br><br>Not sure why you say that. There are other possibilities I'm aware of
<br>here:<br><br>Note that that failed sent MAD is one which has a response expected so<br>this means that the response was not received. It also goes through the<br>transmit retry strategy (I could see this on the SA side). So the only
<br>thing I can say at this point is that for some reason, the response does<br>not make it back from the SA to the SA client (osmtest). That's where<br>this one is right now.<br><br>-- Hal<br><br>> Eitan<br>><br>> Hal Rosenstock wrote:
<br>> > Hi again Viswa,<br>> ><br>> > On Wed, 2005-09-21 at 21:00, Hal Rosenstock wrote:<br>> ><br>> >>Hi Viswa,<br>> >><br>> >>On Wed, 2005-09-21 at 20:23, Viswanath Krishnamurthy wrote:
<br>> >><br>> >>>Currently opensm traps SIGINT. There was some discussion to remove<br>> ><br>> > it.<br>> ><br>> >>>I have currently running some tests on opensm<br>> >>>by killing (SIGKILL) and restarting opensm. So far I ahve not found
<br>> >>>any resource leak issues. Is ther a plan to remove that<br>> >>>signal handler. Ideally it should not exist.<br>> >><br>> >>Eitan stated that this was historical in nature for gen1 drivers which
<br>> >>had resource tracking problems: "if OpenSM left without cleaning up<br>> ><br>> > all<br>> ><br>> >>used resources (like MAD buffers and UD-AVs), the driver oops'ed."<br>
> >><br>> >>I think that (eliminating the handler for SIGINT) can at least be done<br>> >>for OSM_VENDOR_INTF_OPENIB and leave it there for the other vendor<br>> >>layers for starters. I will experiment with gen2 and let you know.
<br>> ><br>> ><br>> > Does the patch below do what you want ? Can you try it ?<br>> ><br>> > -- Hal<br>> ><br>> > Index: opensm/osm_opensm.c<br>> > ===================================================================
<br>> > --- opensm/osm_opensm.c (revision 3513)<br>> > +++ opensm/osm_opensm.c (working copy)<br>> > @@ -182,7 +182,9 @@ osm_reg_sig_handler(<br>> >     IN osm_opensm_t * const p_osm )<br>> >  {
<br>> >     __p_osm_to_signal = p_osm;<br>> > +#ifndef OSM_VENDOR_INTF_OPENIB<br>> >     cl_reg_sig_hdl( SIGINT, __sig_handler );<br>> > +#endif<br>> >     cl_reg_sig_hdl( SIGTERM, __sig_handler );
<br>> >     cl_reg_sig_hdl( SIGHUP, __sig_handler );<br>> >     osm_exit_flag = 0;<br>> ><br>> ><br>> > _______________________________________________<br>> > openib-general mailing list
<br>> > <a href="mailto:openib-general@openib.org">openib-general@openib.org</a><br>> > <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br>> >
<br>> > To unsubscribe, please visit<br>> > <a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a><br>> ><br>><br><br></blockquote></div><br>