Hi Alex, On 5/12/2011 12:14 PM, Alex Netes wrote: > MFTSubnSet failed MADs may leave temporary MC loops in the fabric. > In order to eliminate this faulty state as quick as possible it's a good > thing to initiate a heavy sweep immediately and to wait for the next light > sweep. > > Signed-off-by: Alex Netes <[email protected]> > --- > opensm/osm_state_mgr.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/opensm/osm_state_mgr.c b/opensm/osm_state_mgr.c > index dd308f2..aa71b03 100644 > --- a/opensm/osm_state_mgr.c > +++ b/opensm/osm_state_mgr.c > @@ -1434,6 +1434,13 @@ static void do_process_mgrp_queue(osm_sm_t * sm) > osm_mcast_mgr_process(sm); > wait_for_pending_transactions(&sm->p_subn->p_osm->stats); > } > + > + /* if one or more MFTSubnSet MADs fails > + * during idle process time initiate heavy sweep */ > + if (sm->p_subn->force_heavy_sweep > + || sm->p_subn->subnet_initialization_error) > + osm_sm_signal(sm, OSM_SIGNAL_SWEEP);
subnet_initialization_error is more than just set MFT failures. Should it be narrowed down to just those failures ? Also, while this looks like it would fix the scenario you mention, couldn't this change cause a continual heavy sweep ? -- Hal > + > } > > void osm_state_mgr_process(IN osm_sm_t * sm, IN osm_signal_t signal) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
