<html><body>
<p>Koen,<br>
<br>
Are you using IPv6? If not, then this is no harmful. If you don't use it, you can simply disable loading IPv6 module in your notes when rebooting.<br>
<br>
Thanks<br>
Shirley Ma<br>
IBM Linux Technology Center<br>
15300 SW Koll Parkway<br>
Beaverton, OR 97006-6063<br>
Phone(Fax): (503) 578-7638<br>
<br>
<br>
<img width="16" height="16" src="cid:1__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for "SEGERS Koen" <Koen.SEGERS@VRT.BE>">"SEGERS Koen" <Koen.SEGERS@VRT.BE><br>
<br>
<br>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td style="background-image:url(cid:2__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="40%">
<ul>
<ul>
<ul>
<ul><b><font size="2">"SEGERS Koen" <Koen.SEGERS@VRT.BE></font></b><font size="2"> </font><br>
<font size="2">Sent by: general-bounces@lists.openfabrics.org</font>
<p><font size="2">05/24/07 11:03 AM</font></ul>
</ul>
</ul>
</ul>
</td><td width="60%">
<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">To</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">"Scott Weitzenkamp (sweitzen)" <sweitzen@cisco.com>, "Hal Rosenstock" <halr@voltaire.com></font></td></tr>
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">cc</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">general-bounces@lists.openfabrics.org, general@lists.openfabrics.org</font></td></tr>
<tr valign="top"><td width="1%"><img width="58" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<div align="right"><font size="2">Subject</font></div></td><td width="100%"><img width="1" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="2">RE: [ofa-general] GPFS node loses IB-connection</font></td></tr>
</table>
<table border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="58"><img width="1" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""></td><td width="336"><img width="1" height="1" src="cid:3__=08BBF876DFF7ADC78f9e8a93df938@us.ibm.com" border="0" alt=""></td></tr>
</table>
</td></tr>
</table>
<br>
<font size="4" face="Arial">After changing the switch timeout value, we never got the error again. Yesterday, we started a 24h stresstest. This test was succesfull. I think we can conclude that the problem is fixed now.</font><br>
<font size="4"> </font><br>
<font size="4" face="Arial">But, there is a strange message in de logs of the switch:</font>
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM DELETE_MC_GROUP trap for GID=xx
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM CREATE_MC_GROUP trap for GID=xx
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM DELETE_MC_GROUP trap for GID=xx
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM CREATE_MC_GROUP trap for GID=xx
<p>Topspin-120sc ib_sm.x[618]: %IB-6-INFO: Configuration caused by multicast membership change
<p>Topspin-120sc ib_sm.x[618]: %IB-6-INFO: Configuration caused by multicast membership change
<p><font size="4"> </font>
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM DELETE_MC_GROUP trap for GID=yy
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM CREATE_MC_GROUP trap for GID=yy
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM DELETE_MC_GROUP trap for GID=yy
<p>Topspin-120sc ib_sm.x[632]: %IB-6-INFO: Generate SM CREATE_MC_GROUP trap for GID=yy
<p>Topspin-120sc ib_sm.x[618]: %IB-6-INFO: Configuration caused by multicast membership change
<p>Topspin-120sc ib_sm.x[618]: %IB-6-INFO: Configuration caused by multicast membership change
<p><font size="4"> </font>
<p><font size="4" face="Arial">With xx,yy = (e.g) ff:12:60:1b:ff:ff:00:00:00:00:00:01:ff:05:87:d9 but changing to different GIDs in the next group of loggings each belonging to the IB ports of the server HCA’s.</font>
<p><font size="4" face="Arial">This logging occurs every few minutes (not at a regular interval). Is there somewhere a Cisco manual available that describes or explains these messages? Or can anyone explain what is happening? And whether this can harm a setup that doesn't use multicast?</font>
<p><font size="4" face="Arial">Greetz</font>
<p><font size="4" face="Arial">Koen</font>
<p><font size="4"><br>
</font><hr width="100%" size="2" align="left"><b>Van:</b> Scott Weitzenkamp (sweitzen) [<a href="mailto:sweitzen@cisco.com">mailto:sweitzen@cisco.com</a>]<b><br>
Verzonden:</b> wo 23/05/2007 17:40<b><br>
Aan:</b> SEGERS Koen; Hal Rosenstock<b><br>
CC:</b> Clive Hall (clivhall); general-bounces@lists.openfabrics.org; general@lists.openfabrics.org<b><br>
Onderwerp:</b> RE: [ofa-general] GPFS node loses IB-connection<font size="4"><br>
</font>
<p>Try 20 seconds, I'm curious if if you are barely crossing the 10-second<br>
threshold.<br>
<br>
Scott<br>
<br>
> -----Original Message-----<br>
> From: SEGERS Koen [<a href="mailto:Koen.SEGERS@VRT.BE"><u><font color="#0000FF">mailto:Koen.SEGERS@VRT.BE</font></u></a>]<br>
> Sent: Wednesday, May 23, 2007 8:39 AM<br>
> To: Scott Weitzenkamp (sweitzen); Hal Rosenstock<br>
> Cc: Clive Hall (clivhall);<br>
> general-bounces@lists.openfabrics.org; general@lists.openfabrics.org<br>
> Subject: RE: [ofa-general] GPFS node loses IB-connection<br>
><br>
> What value would you recommend then?<br>
><br>
> Koen<br>
><br>
> -----Oorspronkelijk bericht-----<br>
> Van: Scott Weitzenkamp (sweitzen) [<a href="mailto:sweitzen@cisco.com"><u><font color="#0000FF">mailto:sweitzen@cisco.com</font></u></a>]<br>
> Verzonden: woensdag 23 mei 2007 17:38<br>
> Aan: SEGERS Koen; Hal Rosenstock<br>
> CC: Clive Hall (clivhall); general-bounces@lists.openfabrics.org;<br>
> general@lists.openfabrics.org<br>
> Onderwerp: RE: [ofa-general] GPFS node loses IB-connection<br>
><br>
> The boot time of the host doesn't matter for this timeout. While the<br>
> host is booting, the IB link is down anyway.<br>
><br>
> Scott<br>
><br>
> > -----Original Message-----<br>
> > From: SEGERS Koen [<a href="mailto:Koen.SEGERS@VRT.BE"><u><font color="#0000FF">mailto:Koen.SEGERS@VRT.BE</font></u></a>]<br>
> > Sent: Wednesday, May 23, 2007 8:20 AM<br>
> > To: Hal Rosenstock; Scott Weitzenkamp (sweitzen)<br>
> > Cc: Clive Hall (clivhall);<br>
> > general-bounces@lists.openfabrics.org; general@lists.openfabrics.org<br>
> > Subject: RE: [ofa-general] GPFS node loses IB-connection<br>
> ><br>
> > After a whole day of stresstesting with the MAD renicing<br>
> turned on, we<br>
> > got the error once. So I think I should raise the timeout on<br>
> > the switch<br>
> > also.<br>
> ><br>
> > It takes about 2 minutes to boot the system. Do you agree<br>
> > that this is a<br>
> > good value for the timeout?<br>
> ><br>
> > Scott,<br>
> > Can you explain me the problem of the memlock?<br>
> ><br>
> > I saw that the SLES10 bug is only an issue in MVAPICH.<br>
> Since we didn't<br>
> > install this, the bug is not related to us. This is<br>
> correct, isn't it?<br>
> ><br>
> > Greetz<br>
> ><br>
> > Koen<br>
> ><br>
> > -----Oorspronkelijk bericht-----<br>
> > Van: Hal Rosenstock [<a href="mailto:halr@voltaire.com"><u><font color="#0000FF">mailto:halr@voltaire.com</font></u></a>]<br>
> > Verzonden: woensdag 23 mei 2007 16:12<br>
> > Aan: Scott "Weitzenkamp (sweitzen)<br>
> > CC: SEGERS Koen; Clive Hall (clivhall);<br>
> > general-bounces@lists.openfabrics.org; general@lists.openfabrics.org<br>
> > Onderwerp: RE: [ofa-general] GPFS node loses IB-connection<br>
> ><br>
> > On Wed, 2007-05-23 at 09:51, Scott Weitzenkamp (sweitzen) wrote:<br>
> > > No C code changes, just a few config file changes<br>
> (RENICE_IB_MAD=yes<br>
> > in<br>
> > > openib.conf,<br>
> ><br>
> > Does the host really not respond to MAD requests for over 10<br>
> > seconds in<br>
> > some cases ?<br>
> ><br>
> > -- Hal<br>
> ><br>
> > > memlock in /etc/security/limits.conf, fix /etc/hosts on<br>
> > > SLES10 for bug 267, etc.).<br>
> > ><br>
> > > Scott Weitzenkamp<br>
> > > SQA and Release Manager<br>
> > > Server Virtualization Business Unit<br>
> > > Cisco Systems<br>
> > > <br>
> > ><br>
> > > > -----Original Message-----<br>
> > > > From: SEGERS Koen [<a href="mailto:Koen.SEGERS@VRT.BE"><u><font color="#0000FF">mailto:Koen.SEGERS@VRT.BE</font></u></a>]<br>
> > > > Sent: Wednesday, May 23, 2007 6:48 AM<br>
> > > > To: Scott Weitzenkamp (sweitzen); Clive Hall (clivhall)<br>
> > > > Cc: Shirley Ma; Ami Perlmutter;<br>
> > > > general@lists.openfabrics.org;<br>
> > general-bounces@lists.openfabrics.org<br>
> > > > Subject: RE: [ofa-general] GPFS node loses IB-connection<br>
> > > ><br>
> > > > This far, all tests seem to work.<br>
> > > ><br>
> > > > Thanks for the help!<br>
> > > ><br>
> > > > Scott,<br>
> > > > Are there more bugfixes that cisco does in its rpms?<br>
> > > ><br>
> > > > Greetz<br>
> > > ><br>
> > > > Koen<br>
> > > ><br>
> > > > -----Oorspronkelijk bericht-----<br>
> > > > Van: Scott Weitzenkamp (sweitzen) [<a href="mailto:sweitzen@cisco.com"><u><font color="#0000FF">mailto:sweitzen@cisco.com</font></u></a>]<br>
> > > > Verzonden: woensdag 23 mei 2007 0:39<br>
> > > > Aan: SEGERS Koen; Scott Weitzenkamp (sweitzen); Clive Hall<br>
> > (clivhall)<br>
> > > > CC: Shirley Ma; Ami Perlmutter; general@lists.openfabrics.org;<br>
> > > > general-bounces@lists.openfabrics.org<br>
> > > > Onderwerp: RE: [ofa-general] GPFS node loses IB-connection<br>
> > > ><br>
> > > > It's not so much pinging every 10 seconds as expecting a<br>
> > > > response within<br>
> > > > 10 seconds (Clive, correct me if I'm wrong).<br>
> > > ><br>
> > > > You only need to do 1) or 2), not both. Cisco configures 1)<br>
> > > > in the OFED<br>
> > > > binary RPMs we release at<br>
> > > > <a href="http://www.cisco.com/cgi-bin/tablebuild.pl/sfs-linux"><u><font color="#0000FF">http://www.cisco.com/cgi-bin/tablebuild.pl/sfs-linux</font></u></a>. I<br>
> > > > prefer to have<br>
> > > > the host be more responsive.<br>
> > > ><br>
> > > ><br>
> > > > Scott Weitzenkamp<br>
> > > > SQA and Release Manager<br>
> > > > Server Virtualization Business Unit<br>
> > > > Cisco Systems<br>
> > > > <br>
> > > ><br>
> > > > > -----Original Message-----<br>
> > > > > From: Koen Segers [<a href="mailto:koen.segers@VRT.BE"><u><font color="#0000FF">mailto:koen.segers@VRT.BE</font></u></a>]<br>
> > > > > Sent: Tuesday, May 22, 2007 3:35 PM<br>
> > > > > To: Scott Weitzenkamp (sweitzen)<br>
> > > > > Cc: Shirley Ma; Ami Perlmutter;<br>
> > > > > general@lists.openfabrics.org;<br>
> > general-bounces@lists.openfabrics.org<br>
> > > > > Subject: RE: [ofa-general] GPFS node loses IB-connection<br>
> > > > ><br>
> > > > > If I understand it wright, the switch is actually polling<br>
> > > > > (=pinging) the<br>
> > > > > interfaces every 10s. This means that when the interface is<br>
> > handling<br>
> > > > > other traffic, the poll can fail and the port could be<br>
> > > > > considered out of<br>
> > > > > service. My question is then: "How can the timeout be reached<br>
> > while<br>
> > > > > packets are being sent/received to/from the interface?"<br>
> > > > ><br>
> > > > > Anyway, what timeout-value would you recommend for<br>
> us? And why?<br>
> > > > ><br>
> > > > > To recapitulate: these are the actions I'll take tomorrow<br>
> > > > > 1) change the MAD niceness of the servers<br>
> > > > > 2) change the timeout on the switches<br>
> > > > ><br>
> > > > > Are these changes sufficient for the HCA's to keep<br>
> > their ports in<br>
> > > > > PORT_ACTIVE state?<br>
> > > > ><br>
> > > > > Regards,<br>
> > > > ><br>
> > > > > Koen<br>
> > > > ><br>
> > > > > On Tue, 2007-05-22 at 12:59 -0700, Scott Weitzenkamp<br>
> > > > (sweitzen) wrote:<br>
> > > > > > Yes, you can tune it. Here's an example via the switch CLI:<br>
> > > > > > <br>
> > > > > > SFS-7000D(config)# ib sm subnet-prefix<br>
> fe:80:00:00:00:00:00:00<br>
> > > > > > node-timeout <value><br>
> > > > > ><br>
> > > > > > The default is 10 seconds, it can be configured up to<br>
> > > > 2000 seconds.<br>
> > > > > > If a HCA is completely unresponsive for longer than the<br>
> > > > node-timeout<br>
> > > > > > value, then we consider that HCA out of service.<br>
> > > > > > <br>
> > > > > > Scott Weitzenkamp<br>
> > > > > > SQA and Release Manager<br>
> > > > > > Server Virtualization Business Unit<br>
> > > > > > Cisco Systems<br>
> > > > > > <br>
> > > > > ><br>
> > > > > > <br>
> > > > > > <br>
> > > > > ______________________________________________________________<br>
> > > > > > From: Shirley Ma [<a href="mailto:xma@us.ibm.com"><u><font color="#0000FF">mailto:xma@us.ibm.com</font></u></a>]<br>
> > > > > > Sent: Tuesday, May 22, 2007 11:30 AM<br>
> > > > > > To: koen.segers@VRT.BE<br>
> > > > > > Cc: Ami Perlmutter; general@lists.openfabrics.org;<br>
> > > > > > general-bounces@lists.openfabrics.org; Scott<br>
> > Weitzenkamp<br>
> > > > > > (sweitzen)<br>
> > > > > > Subject: RE: [ofa-general] GPFS node loses<br>
> > IB-connection<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > > > > Koen,<br>
> > > > > > <br>
> > > > > > So it is most likely you hit the same bug as<br>
> > 229 (Scott<br>
> > > > > > pointed out earlier). The same workaround might<br>
> > > > work for you<br>
> > > > > > by renicing ib_mad as Scott suggested.<br>
> > > > > > <br>
> > > > > > I think this should be a SM query timeout<br>
> > tunable value<br>
> > in<br>
> > > > > > Cisco SM. Am I right, Scott?<br>
> > > > > > <br>
> > > > > > Thanks<br>
> > > > > > Shirley Ma<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > Inactive hide details for Koen Segers<br>
> > > > > <koen.segers@VRT.BE>Koen<br>
> > > > > > Segers <koen.segers@VRT.BE><br>
> > > > > > <br>
> > > > > > <br>
> > > > > > Koen Segers<br>
> > > > > <koen.segers@VRT.BE><br>
> > > > > > <br>
> > > > > > 05/22/07 11:14 AM<br>
> > > > > > Please respond to<br>
> > > > > > koen.segers@VRT.BE<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > To<br>
> > > > > > <br>
> > > > > > Shirley<br>
> > > > > > Ma/Beaverton/IBM@IBMUS<br>
> > > > > > <br>
> > > > > > cc<br>
> > > > > > <br>
> > > > > > Ami Perlmutter<br>
> > > > > > <amip@dev.mellanox.co.il>,<br>
> > > > > general@lists.openfabrics.org,<br>
> > general-bounces@lists.openfabrics.org<br>
> > > > > > <br>
> > > > > > Subject<br>
> > > > > > <br>
> > > > > > RE:<br>
> > > > > > [ofa-general]<br>
> > > > > > GPFS node loses<br>
> > > > > > IB-connection<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > > > > Hi,<br>
> > > > > > <br>
> > > > > > It is the Cisco SM.<br>
> > > > > > <br>
> > > > > > SFS-7000P> show version<br>
> > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > > > ==============================================================<br>
> > > > > ==================<br>
> > > > > > System Version Information<br>
> > > > > > <br>
> > > > > ==============================================================<br>
> > > > > ==================<br>
> > > > > > system-version : SFS-7000P TopspinOS<br>
> > > > 2.9.0 releng<br>
> > > > > > #147<br>
> > > > > > 10/25/2006 02:01:32<br>
> > > > > > contact : tac@cisco.com<br>
> > > > > > name : SFS-7000P<br>
> > > > > > location : 170 West Tasman Drive,<br>
> > > > > San Jose, CA<br>
> > > > > > 95134<br>
> > > > > > up-time : 11(d):7(h):49(m):3(s)<br>
> > > > > > last-change : none<br>
> > > > > > last-config-save : none<br>
> > > > > > action : none<br>
> > > > > > result : none<br>
> > > > > > oper-mode : normal<br>
> > > > > > <br>
> > > > > > There is also a command that gives the SM version,<br>
> > > > > but I can't<br>
> > > > > > find it<br>
> > > > > > right now.<br>
> > > > > > <br>
> > > > > > On Tue, 2007-05-22 at 09:45 -0700, Shirley Ma wrote:<br>
> > > > > > > Hello Koen,<br>
> > > > > > ><br>
> > > > > > > From the switch log, it looks a SM issue to me.<br>
> > > > > The node was<br>
> > > > > > kicked<br>
> > > > > > > out of the membership. Which SM you are<br>
> > using in your<br>
> > > > > > fabric?<br>
> > > > > > ><br>
> > > > > > > Thanks<br>
> > > > > > > Shirley Ma<br>
> > > > > > ><br>
> > > > > > *** Disclaimer ***<br>
> > > > > > <br>
> > > > > > Vlaamse Radio- en Televisieomroep<br>
> > > > > > Auguste Reyerslaan 52, 1043 Brussel<br>
> > > > > > <br>
> > > > > > nv van publiek recht<br>
> > > > > > BTW BE 0244.142.664<br>
> > > > > > RPR Brussel<br>
> > > > > > <a href="http://www.vrt.be/disclaimer"><u><font color="#0000FF">http://www.vrt.be/disclaimer</font></u></a><br>
> > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > > > > <br>
> > > > > *** Disclaimer ***<br>
> > > > ><br>
> > > > > Vlaamse Radio- en Televisieomroep<br>
> > > > > Auguste Reyerslaan 52, 1043 Brussel<br>
> > > > ><br>
> > > > > nv van publiek recht<br>
> > > > > BTW BE 0244.142.664<br>
> > > > > RPR Brussel<br>
> > > > > <a href="http://www.vrt.be/disclaimer"><u><font color="#0000FF">http://www.vrt.be/disclaimer</font></u></a><br>
> > > > > <br>
> > > > ><br>
> > > > *** Disclaimer ***<br>
> > > ><br>
> > > > Vlaamse Radio- en Televisieomroep<br>
> > > > Auguste Reyerslaan 52, 1043 Brussel<br>
> > > ><br>
> > > > nv van publiek recht<br>
> > > > BTW BE 0244.142.664<br>
> > > > RPR Brussel<br>
> > > > <a href="http://www.vrt.be/disclaimer"><u><font color="#0000FF">http://www.vrt.be/disclaimer</font></u></a><br>
> > > > <br>
> > > ><br>
> > > _______________________________________________<br>
> > > general mailing list<br>
> > > general@lists.openfabrics.org<br>
> > > <a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general"><u><font color="#0000FF">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</font></u></a><br>
> > ><br>
> > > To unsubscribe, please visit<br>
> > <a href="http://openib.org/mailman/listinfo/openib-general"><u><font color="#0000FF">http://openib.org/mailman/listinfo/openib-general</font></u></a><br>
> ><br>
> > *** Disclaimer ***<br>
> ><br>
> > Vlaamse Radio- en Televisieomroep<br>
> > Auguste Reyerslaan 52, 1043 Brussel<br>
> ><br>
> > nv van publiek recht<br>
> > BTW BE 0244.142.664<br>
> > RPR Brussel<br>
> > <a href="http://www.vrt.be/disclaimer"><u><font color="#0000FF">http://www.vrt.be/disclaimer</font></u></a><br>
> > <br>
> ><br>
> *** Disclaimer ***<br>
><br>
> Vlaamse Radio- en Televisieomroep<br>
> Auguste Reyerslaan 52, 1043 Brussel<br>
><br>
> nv van publiek recht<br>
> BTW BE 0244.142.664<br>
> RPR Brussel<br>
> <a href="http://www.vrt.be/disclaimer"><u><font color="#0000FF">http://www.vrt.be/disclaimer</font></u></a><br>
> <br>
>
<p><font size="4">*** Disclaimer ***<br>
<br>
Vlaamse Radio- en Televisieomroep<br>
Auguste Reyerslaan 52, 1043 Brussel<br>
<br>
nv van publiek recht<br>
BTW BE 0244.142.664<br>
RPR Brussel<br>
</font><font size="4"><a href="http://www.vrt.be/disclaimer">http://www.vrt.be/disclaimer</a></font><font size="4"><br>
</font><tt>_______________________________________________<br>
general mailing list<br>
general@lists.openfabrics.org<br>
</tt><tt><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a></tt><tt><br>
<br>
To unsubscribe, please visit </tt><tt><a href="http://openib.org/mailman/listinfo/openib-general">http://openib.org/mailman/listinfo/openib-general</a></tt>
<p></body></html>