<font size=2 face="sans-serif">Hal,</font>
<br>
<br><font size=2 face="sans-serif">Thank you for the response. To address
your questions:</font>
<br>
<br><tt><font size=2>> So the switch stays up and the servers (including
the one OpenSM is on)<br>
> is rebooted, right ?</font></tt>
<br>
<br><tt><font size=2>Right.</font></tt>
<br>
<br><tt><font size=2>> Do the servers run QNX rather than Linux ? Are
you saying all OpenSM<br>
> code is the same as stock OpenSM 3.3.12 (OFED 1.5.4-rc3) ?</font></tt>
<br>
<br><tt><font size=2>Yes, all 7 servers run QNX. The OpenSM code is 99%
the same, the only changes I had to make were made to some #define libraries.</font></tt>
<br><tt><font size=2>The big changes were made for the driver, not so much
OpenSM. I'm using IBNet 1.3. OpenSM always runs on the same one server,
the others don't run it.</font></tt>
<br>
<br><tt><font size=2>> Is the topology the 7 servers and the 1 switch
and if you use other<br>
> switches you don't see this issue ?</font></tt>
<br>
<br><tt><font size=2>That's correct, the topology is 7 servers and 1 switch.
We typically use less servers (4) for our application but the problem is
more easily reproducible with more servers so we have a 7 server setup
with 1 switch. We don't have a great selection of switches but I know our
previous switch did not cause this problem. Our intention is to go to production
with this new switch but we can't release until we find an acceptable solution.</font></tt>
<br>
<br><tt><font size=2>>Ican see the responses but not the requests. What
verbosity level did<br>
> you use ?</font></tt>
<br>
<br><tt><font size=2>I ran OpenSM with level -D 0x06 (error, info, verbose).
I don't want to do -D 0xFF because I know this fixes the problem for sure.</font></tt>
<br>
<br><tt><font size=2>-------------------------</font></tt>
<br>
<br><tt><font size=2>In summary:</font></tt>
<br><tt><font size=2>1.        knowing that
the system gets stuck for sm_vendor_ibumad.c -> umad_receiver() ->
"for(;;)" but keeps running properly for function main.c ->
osm_manager_loop().</font></tt>
<br><tt><font size=2>2.        If I use -D
0xFF the problem is completely fixed</font></tt>
<br><tt><font size=2>3.        if I use OSM_DEFAULT_SMP_MAX_ON_WIRE
of 1 instead of any other value the problem is completely fixed</font></tt>
<br><tt><font size=2>4.        The failure
always occurs with qp0_mads_outstanding of 1 remaining</font></tt>
<br><tt><font size=2>what do you think could be wrong?</font></tt>
<br><font size=2 face="sans-serif">Do you think the driver could be the
problem?</font>
<br><font size=2 face="sans-serif">What debug command should I use to see
the sent requests?</font>
<br>
<br><font size=2 face="sans-serif">Thank you</font>
<br>
<br><font size=2 face="sans-serif">Hector Abrach</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Hal Rosenstock <hal@dev.mellanox.co.il></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Hector Abrach <HAbrach@TMRIUSA.COM></font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">ewg@lists.openfabrics.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">12/14/2011 08:23 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [ewg] OpenSM 1.5.4 Boot Problem</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hector,<br>
<br>
On 12/14/2011 1:41 PM, Hector Abrach wrote:<br>
> Hal,<br>
> <br>
> Sorry for the multiple emails, but I was thinking how it may be a<br>
> "freeze /stall" rather than a time out.  One reason
is that it doesn't<br>
> send an error message, is as if the log completely dies.<br>
<br>
So nothing interesting in the log...<br>
<br>
> However, in<br>
> file osm_vendor_ibumad.c under function umad_receiver there is an<br>
> infinite loop "for(;;)" which seems to die when I get to
that previously<br>
> discussed vl15_poller. I checked to see if it breaks out of the loop
but<br>
> it doesn't seem to. <br>
<br>
It never breaks out of that loop except when OpenSM is shutting down.<br>
That's the basic receive loop.<br>
<br>
-- Hal<br>
<br>
> I'm not sure if this may be an additional hint.<br>
> Thank you<br>
> <br>
> Hector Abrach<br>
> <br>
> <br>
> From:                
 Hector Abrach <HAbrach@TMRIUSA.COM><br>
> To:                
 Hal Rosenstock <hal@dev.mellanox.co.il><br>
> Cc:                
 ewg@lists.openfabrics.org<br>
> Date:                
 12/14/2011 11:15 AM<br>
> Subject:              
   Re: [ewg] OpenSM 1.5.4 Boot Problem<br>
> Sent by:              
   ewg-bounces@lists.openfabrics.org<br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> <br>
> <br>
> <br>
> Hal,<br>
> <br>
> Thank you very much for the support, I am the same person from the
gmail<br>
> account so I will respond through here.<br>
> <br>
> Attached is a picture of the switch serial number:<br>
> <br>
> <br>
> <br>
> I am indeed using OFED 1.5.4-rc3. My experiment consists of a 7 server<br>
> system which I reboot via a script over and over again. Technically<br>
> speaking the switch is not being powered off or physically rebooted.
My<br>
> server system is what is being rebooted. I am running OpenSM on one
of<br>
> the 7 servers. This means I'm constantly shutting down and rebooting<br>
> OpenSM. I am running OpenSM on QNX but we have not had this problem<br>
> until we decided to upgrade to this switch.<br>
> <br>
> The problem is that every 1 out of 15 of this remote reboots OpenSM<br>
> stalls or times out because stats->qp0_mads_outstanding did not
reach<br>
> zero. Please excuse my ignorance as I'm relatively new at this but
how<br>
> do I verify if it is a timeout problem vs a stall?<br>
> <br>
> You also mentioned that you'd like to see the Verbose output of openSM;<br>
> however, when I run in Verbose mode I don't see the problem. It appears<br>
> as if the verbose output stalls enough time to give the switch time
to<br>
> do what ever it needs to do and hence not have the problem occur.
But<br>
> this is the last I see when the problem occurs:<br>
> <br>
> <br>
> <br>
> -------------------------------------------------<br>
> OpenSM 3.3.12<br>
> Command Line Arguments:<br>
> Log file max size is 5 MBytes<br>
> Log File: /tmp/opensm.log<br>
> -------------------------------------------------<br>
> OpenSM 3.3.12<br>
> <br>
> Entering DISCOVERING state<br>
> <br>
> Using default GUID 0x2c9020023277d<br>
> <br>
> <br>
> <br>
> The problem occurs in function osm_vl15intf.c -> vl15_poller in
the else<br>
> statement.<br>
> <br>
> if (p_madw != (osm_madw_t *) cl_qlist_end(p_fifo)) {<br>
>        OSM_LOG(p_vl->p_log, OSM_LOG_DEBUG,<br>
>        "Servicing p_madw = %p\n", p_madw);<br>
>        if (osm_log_is_active(p_vl->p_log, OSM_LOG_FRAMES))<br>
>        osm_dump_dr_smp(p_vl->p_log,<br>
>        osm_madw_get_smp_ptr(p_madw),<br>
>        OSM_LOG_FRAMES);<br>
> <br>
>        vl15_send_mad(p_vl, p_madw);<br>
> } else<br>
>        /*<br>
>           The VL15 FIFO is empty, so we have
nothing left to do.<br>
>         */<br>
>        status = cl_event_wait_on(&p_vl->signal,<br>
>                  EVENT_NO_TIMEOUT,
TRUE);<br>
> <br>
> It won't move forward from the cl_event_wait_on in this line of code.<br>
> However, there are other locations such as wait_for_pending_transactions<br>
> in the do_sweep function that won't move forward from. But I believe<br>
> this to be a side effect of the problem I'm mentioning.<br>
> <br>
> When you mention what is my timeout, I'm guessing you refer to<br>
> max_smps_timeout which is used in the second while loop within<br>
> vl15_poller? For this setting I am using the default which is defined
in<br>
> osm_subnet.c as:<br>
> <br>
> p_opt->transaction_timeout = OSM_DEFAULT_TRANS_TIMEOUT_MILLISEC;<br>
>    p_opt->transaction_retries = OSM_DEFAULT_RETRY_COUNT;<br>
>    p_opt->max_smps_timeout = 1000 * p_opt->transaction_timeout<br>
> *p_opt->transaction_retries;<br>
> <br>
> Would you explain to me what are the advantages or disadvantages of<br>
> OSM_DEFAULT_SMP_MAX_ON_WIRE? Does this parameter change my bandwidth<br>
> performance at all?<br>
> <br>
> I noticed that when using the default setting of 4 I get into the
else<br>
> of the above if statement when there are 4 qp0_mads_outstanding. I<br>
> noticed that if I change OSM_DEFAULT_SMP_MAX_ON_WIRE to 1 I don't
get<br>
> the failure I'm mentioning at all. Partly (I think) because I don't<br>
> enter the else in the if statement until there is 1 qp0_mads_outstanding.<br>
> <br>
> I hope this explains the problem well enough and it may be a time
out<br>
> problem but I'd like to understand why the problem is occurring.<br>
> Thank you very much,<br>
> <br>
> Hector Abrach<br>
> <br>
> From:                
Hal Rosenstock <hal@dev.mellanox.co.il><br>
> To:                
Hector Abrach <HAbrach@TMRIUSA.COM><br>
> Cc:                
ewg@lists.openfabrics.org<br>
> Date:                
12/14/2011 08:03 AM<br>
> Subject:              
  Re: [ewg] OpenSM 1.5.4 Boot Problem<br>
> <br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> <br>
> <br>
> <br>
> Hi,<br>
> <br>
> On 12/13/2011 2:35 PM, Hector Abrach wrote:<br>
>> Hello,<br>
>><br>
>> I have a boot problem with OpenSM<br>
> <br>
> Are you saying the switch is booted rather than OpenSM ?<br>
> <br>
> What is the OpenSM running on and in what environment ?<br>
> <br>
>> the problem occurs seldomly and<br>
>> started to ocur when we started using a new Mellanox MT1118X03342
switch.<br>
>> The problem occurs during the discovery phase within<br>
> state_mgr_sweep_hop_1.<br>
>><br>
>> However, I discovered that the actual location is because the<br>
>> qp0_mads_outsanding stalls at 1 occasionally.<br>
> <br>
> Is it stuck or after timeout/retry does this get updated properly
?<br>
> <br>
>> Within file osm_vl15intf.c in function vl15_poller it checks at
the<br>
>> rfifo and if the qlist still has items it applies function vl15_send_mad<br>
>> which later on triggers the signal.<br>
>> With the current default setting of 4 for OSM_DEFAULT_SMP_MAX_ON_WIRE
I<br>
>> noticed that cl_qlist_end reaches zero before<br>
>> stats->qp0_mads_outstanding does. This causes a stall in<br>
>> cl_event_wait_on. The rfifo always reaches 0 when there are 4<br>
>> qp0_mads_outstanding however when it fails it always fails when
there is<br>
>> 1 qp0_mad_outstanding.<br>
> <br>
> Is some (request) SMP that OpenSM sent timing out (not being responded
to) ?<br>
> <br>
>> Have you seen this failure? By the way, I see this failure once
every 15<br>
>> reboots approximately.<br>
>><br>
>> I discovered that changing OSM_DEFAULT_SMP_MAX_ON_WIRE to 1 fixes
the<br>
>> problem.<br>
> <br>
> What do you mean exactly by fixes the problem ? I'm not sure I<br>
> understand what the problem is yet.<br>
> <br>
> -- Hal<br>
> <br>
>> My guess is that there is a race condition when the switch sends
4 SMPs<br>
>> in parallel. Also, this failure only appears to occur at reboot.
Another<br>
>> solution which is not acceptable is when I add a delay in the
process<br>
>> the failure goes away. This as if the switch needed more time
to do<br>
>> something.<br>
>><br>
>> I would really appreciate your help and insight.<br>
>> Thank you<br>
>><br>
>> Hector Abrach<br>
>> ______________________________________________________________________<br>
>> This email has been scanned by the Symantec Email Security.cloud
service.<br>
>> For more information please visit _http://www.symanteccloud.com_<br>
> <</font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com/</font></tt></a><tt><font size=2>><br>
>> ______________________________________________________________________<br>
>><br>
>><br>
>> _______________________________________________<br>
>> ewg mailing list<br>
>> ewg@lists.openfabrics.org<br>
>> _http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg_<br>
> <br>
> <br>
> ______________________________________________________________________<br>
> This email has been scanned by the Symantec Email Security.cloud service.<br>
> For more information please visit _http://www.symanteccloud.com_<br>
> <</font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com/</font></tt></a><tt><font size=2>><br>
> ______________________________________________________________________<br>
> <br>
> <br>
> ______________________________________________________________________<br>
> This email has been scanned by the Symantec Email Security.cloud service.<br>
> For more information please visit </font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com</font></tt></a><tt><font size=2><br>
> <</font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com/</font></tt></a><tt><font size=2>><br>
> ______________________________________________________________________<br>
> <br>
> ______________________________________________________________________<br>
> This email has been scanned by the Symantec Email Security.cloud service.<br>
> For more information please visit </font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com</font></tt></a><tt><font size=2><br>
> <</font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com/</font></tt></a><tt><font size=2>><br>
> ______________________________________________________________________[attachment<br>
> "2011-12-13_10-18-25_182.jpg" deleted by Hector Abrach/Software/TMRU]<br>
> _______________________________________________<br>
> ewg mailing list<br>
> ewg@lists.openfabrics.org<br>
> </font></tt><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg"><tt><font size=2>http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg</font></tt></a><tt><font size=2><br>
> <br>
> ______________________________________________________________________<br>
> This email has been scanned by the Symantec Email Security.cloud service.<br>
> For more information please visit </font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com</font></tt></a><tt><font size=2><br>
> ______________________________________________________________________<br>
<br>
<br>
______________________________________________________________________<br>
This email has been scanned by the Symantec Email Security.cloud service.<br>
For more information please visit </font></tt><a href=http://www.symanteccloud.com/><tt><font size=2>http://www.symanteccloud.com</font></tt></a><tt><font size=2><br>
______________________________________________________________________<br>
</font></tt>
<br>
<br clear="both">
______________________________________________________________________<BR>
This email has been scanned by the Symantec Email Security.cloud service.<BR>
For more information please visit http://www.symanteccloud.com<BR>
______________________________________________________________________<BR>