Hi Eitan,<br>

<br>

I see that message in the log. <br>

<br>

-Viswa<br>

<br><br><div><span class="gmail_quote">On 9/24/05, <b class="gmail_sendername">Eitan Zahavi</b> <<a href="mailto:eitan@mellanox.co.il">eitan@mellanox.co.il</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 Viswa and Hal,<br><br>I have read through the thread and have few comments.<br><br>But first let me see if I understand the test run correctly. The test is as follows:<br>1. OpenSM starts up configuring the subnet.<br>

2. Then the user ears up a cable and connects it to the other side port of a switch<br>3. The SM is supposed to bring up the new connection<br>4. Step 2 is repeated until the SM stops responding.<br><br>Well, if this is the case then OpenSM is might stop responding due to the following features:

<br>1. We had in the past cases where bad hardware continuously flooded the SM with Traps.<br>    To protect against this kind of DOS attack we have implemented an adaptive filter in<br>    the SM trap receiver:<br>    If the exact same trap is received continuously from same source more then 10 times

<br>    (with no more then of 5sec between the traps) they are considered DOS and are ignored.<br>    Please see osm_trap_rcv.c for details.<br>2. The way IB switches work is that each time a port of their changes state they:

<br>    a. Set the "change bit" in the SwitchInfo<br>    b. Send a trap 128 to the SM. But Trap 128 does not carry the changed port number.<br><br>So under a test case like you describe what can happen:<br>1. The SM decides to ignore trap 128 from the switch as more then 5 connect/reconnect sequences

<br>    happen with not enough "quite" time to recover.<br>2. The SwitchInfo ChangeBit is sampled during the OSM light sweep. There is a race between the<br>    reading of the change bit and the clearing of it. If the connect disconnect happen very fast

<br>    the change bit set by the re-connect can be cleaned by the clear starting by the disconnect.<br><br>It is easy to see in the log file if the SM did ignore traps. Run with -V and look for:<br>grep "Continuously received this trap" /var/log/osm.log

<br><br>(for some reason I did not get any log attachments with this thread - otherwise I would<br>do some analysis on it too).<br><br>Anyway, if the SM does not heavy sweep (due to the above) it is very likely it will continue to

<br>poll the non existing node that was previously attached to a switch port with no success.<br><br>So testing of cable tear off and reconnect should be done with at least 10 seconds recovery time.<br>Also you could try sending kill -HUP to the OpenSM process and see if the full sweep you start

<br>is able to bring all ports up.<br><br>Viswa, with all that said, it is very possible you are experiencing a bug in OpenSM and we<br>want to encourage your effort finding those. With your, and others, help we will be able to

<br>flush them out.<br><br>Thanks<br><br>Eitan<br><br>Hal Rosenstock wrote:<br>> On Fri, 2005-09-23 at 14:57, Hal Rosenstock wrote:<br>><br>>>On Fri, 2005-09-23 at 13:50, Viswanath Krishnamurthy wrote:<br>>>

<br>>>>- After 7-8 iterations, I ran into a weird problem, where opensm was<br>>>>showing the HCA as UNKNOWN. The port<br>>>>never came up to ACTIVE state.  The unplugged and replugged into<br>>>>different slots, the port remained in INIT

<br>>>>state.<br>>><br>>>Mellanox    :

SW : 12 : INI

:      :     : 2048 :

1x  : 2.5 :<br>><br>> 0002c9010d26e780 : UNKNOWN<br>><br>>>OpenSM thinks that either there is no physical port on the other end<br>><br>> of<br>><br>>>the link or it is not "valid" (GUID non 0). Obviously it is there as

> > the > >>port state is INIT so the physical link came up which requires the >>remote end to be there. > > >>From the log you sent, this is exactly what is happening.

<br>> Sep 23 10:07:23 451191 [B7751BB0] -> osm_drop_mgr_process: Checking port<br>> 0x0002c9010d26e780.<br>> Sep 23 10:07:23 451209 [B7751BB0] -> osm_drop_mgr_process: Checking port<br>> 0x0002c90200400cfd.

<br>> Sep 23 10:07:23 451226 [B7751BB0] -> osm_drop_mgr_process: ERR 0108:<br>> Unknown remote side for node 0x0002c9010d26e780 port 20. Adding to light<br>> sweep sampling list.<br>> Sep 23 10:07:23 451251 [B7751BB0] -> Directed Path Dump of 1 hop path:

<br>>                                

Path = [0][1]<br>> Sep 23 10:07:23 451267 [B7751BB0] -> osm_drop_mgr_process: ]<br>><br>> So look in osm_drop_mgr.c line 707:<br>> Can you enhance the log display to see which is failing:<br>> osm_physp_is_valid(p_physp) or osm_physp_get_remote(p_physp) ?

<br>><br>> Also, it appears to keep light sweeping this port but whichever switch<br>> port it is on, it does not respond. Not sure where the problem is. It<br>> could be on the outgoing side of the switch (we could run diags against

<br>> the switch and various ports; I would be curious what they return when<br>> the subnet is in this broken state) or on the HCA. However, the fact<br>> that restarting opensm made it go away without touching anything else

<br>> makes this appear otherwise.<br>><br>><br>>>One other note is that it appears to have come up as 1x. Is that what<br>>>should happen ?<br>><br>><br>> -- Hal<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></blockquote></div><br>