Moore, Eric wrote: > > On Monday, May 22, 2006 11:35 AM, Michael Reed wrote: >>> It's not so transient during reset processing. I've measured 10 to >>> 15 seconds of elapsed time. But, it always eventually succeeds. >> Well, I should have said that the event occurs with some regularity >> during reset processing. And that the duration of the EAGAIN response >> is 10 to 15 seconds. I'd rather reschedule than msleep. >> > > Why? > > Anyways ... if were going to sleep, I'd rather the sleeping/waiting be > done > from mpt_config when were are calling mpt_get_msg_frame(), instead > of the calling functions. Perhaps mpt_get_msg_frame triggering a signal > or something when its having a freed mf. Changing mpt_config() to sleep changes the behavior in that EAGAIN might no longer be returned. lan, ctl, sas, spi, and fc all make use of mpt_config(). This may be non-trivial with regard to testing. Or it may not. And, as James points out, we have to assure that the caller is in a context which can sleep. Can we leave the interface alone for the moment and accept the patch as written? Then, look at changing mpt_config() and the evaluate the testing burden that the change might impose? My vested interest is in getting the functionality into certain distros of interest. I have no problem with rearchitecting the patchset as described above. I'm just concerned with the timing. I suspect that the testing required will push the patch's acceptance beyond my potential window of opportunity. As written, the change is confined to fibre channel so will not potentially introduce regressions into the other drivers. Thanks, Mike > > Eric > - > : 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 > > - : 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
