Yes, I noticed that we stop processing as soon as we find a device that has change count. We should go through all the devices that have change counts. At least, in FCP world an RSCN (similar to BROADCAST in SAS) may be delayed by the Fabric to collect few changes. Thanks, Malahal. Alexis Bruemmer [alexisb@xxxxxxxxxx] wrote: > On Tue, 2006-10-03 at 09:19 -0500, James Bottomley wrote: > > On Tue, 2006-09-26 at 15:05 -0700, Alexis Bruemmer wrote: > > > In some cases while hotplugging disks on a system with an expander the > > > broadcast primitive will be posted and begin processing before the > > > expander change count is updated. This causes the device that triggered > > > the broadcast to not be found. > > > > Thanks; I'll stick this in. > > > > However, it has always struck me that this broadcast code is fragile > > because of the way event processing works. If we get two fairly close > > together broadcast events, we'll amalgamate them into a single event and > > then stop processing as soon as we find one expander that changed, if > > you want to look at sorting that out ... > > I will look into it. > > --Alexis - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
