Hi Sasha Let's assume someone has reset a switch on the fabric. What would cause the SM to re-assign the LFT of that switch? I assumed that there is a mechanism to do that.
Anyway, kill -HUP should flush out the state and restart from scratch. Eitan > -----Original Message----- > From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] > Sent: Sunday, July 22, 2007 1:22 PM > To: Eitan Zahavi > Cc: OPENIB; [EMAIL PROTECTED]; Yevgeny Kliteynik > Subject: Re: opensm: a bug in heavy sweep? - no LFT re-configuration > > Hi Eitan, > > On 09:36 Sun 22 Jul , Eitan Zahavi wrote: > > Hi Sasha > > > > I am running some tests manually and apparently it looks > like I found > > a bug. Here is the sequence of things: > > 1. SM sweeps the fabric assign LFTs > > 2. I manually modify some LFTs (single entry now marked > UNREACHABLE 3. > > I force some switch change bit to 1 or issue kill -HUP 4. The SM > > reports SUBNET UP 5. The modified LFT entry is still > UNREACHABLE and > > the path is broken > > Right, in most cases (unless OpenSM has its own changes in > the same LFT > block) OpenSM will refer its own LFT image for "need to update" > decision, so _manual_ changes will not trigger new update. > Rerunning OpenSM should help however. > > > It looks to me some optimization of routing does not fully reroute > > unless some condition is met - but that condition does not > include the > > above triggers listed in step 3. > > Rereading all fabrics LFTs by default seems to be too > expensive operations. At least by default, if it is real > requirement this could be enforced manually, for example when > kill -HUP is used. Thoughts? > > Sasha > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
