Yes, if you build it from source. The same change should apply. If it doesn't automatically apply, it's simple to hand edit this one line change and rebuild. -- Hal
________________________________ From: Bub Thomas [mailto:[EMAIL PROTECTED] Sent: Tue 11/14/2006 6:48 AM To: Sasha Khapyorsky; Hal Rosenstock; Bub Thomas Cc: Sean Hefty; Erez Cohen; [email protected] Subject: RE: [openib-general] Unusable QP's on CM established connections from gen2 client to gen1 server. I don't have a svn repository. I'm living on OFED release will this work on the version in OFED-1.1? Thomas > -----Original Message----- > From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] > Sent: Monday, November 13, 2006 9:12 PM > To: Hal Rosenstock; Bub Thomas > Cc: Sean Hefty; Erez Cohen; [email protected] > Subject: Re: [openib-general] Unusable QP's on CM established connections > from gen2 client to gen1 server. > > On 19:49 Mon 13 Nov , Hal Rosenstock wrote: > > There may be an OpenSM bug with setting hop limit in the path record > response. I'm looking at it now. > > Looks like it is - OpenSM returns the same hop_limit value as was in the > request. > > Bub, could you try the patch below? > > Thanks, > Sasha > > > diff --git a/osm/opensm/osm_sa_path_record.c > b/osm/opensm/osm_sa_path_record.c > index 560e385..72a89d0 100644 > --- a/osm/opensm/osm_sa_path_record.c > +++ b/osm/opensm/osm_sa_path_record.c > @@ -709,6 +710,8 @@ __osm_pr_rcv_build_pr( > p_pr->dlid = cl_hton16( dest_lid_ho ); > p_pr->slid = cl_hton16( src_lid_ho ); > > + p_pr->hop_flow_raw &= cl_hton32(1<<31); > + > p_pr->pkey = p_parms->pkey; > p_pr->sl = cl_hton16(p_parms->sl); > p_pr->mtu = (uint8_t)(p_parms->mtu | 0x80); > > > > > > -- Hal > > > > ________________________________ > > > > From: [EMAIL PROTECTED] on behalf of Sean Hefty > > Sent: Mon 11/13/2006 11:26 AM > > To: Bub Thomas > > Cc: Erez Cohen; [email protected] > > Subject: Re: [openib-general] Unusable QP's on CM established > connections from gen2 client to gen1 server. > > > > > > > > Bub Thomas wrote: > > > Setting the hop_limit from 64 down to 0 or 1 solved the problem. :-) > > > Don't ask me where I got that hop_limit from, it must have been an > > > example I found somewhere. > > > Can you explain why that hop_limit/is_global makes a difference in > > > communication between gen1 and gen2? Does the counterpart need to have > > > the same hop_limit? > > > > The gen2 stack uses a hop_limit > 0 to indicate that global routing is > being > > used. If the hop_limit is > 0, then the global routing information must > be valid. > > > > > The path record values I use are queried from the OSM using a > > > SERVICE_RECORD query followed by a path record query. > > > I'm not using any alternate path record values, is this critical? > > > > Everything is supposed to work with the path records returned from the > SM. I > > was wondering if you were querying for the path record, modifying the > returned > > value, or creating a path record yourself. > > > > > path_record.packet_life_time = 0; > > > > I would set this higher (maybe between 12-20, with: 18 = 1 second, 19 = > 2 > > seconds, 20 = 4 seconds, etc.) > > > > _______________________________________________ > > openib-general mailing list > > [email protected] > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- > general > > > > > > > > > > _______________________________________________ > > openib-general mailing list > > [email protected] > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- > general > > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
