Re: [PATCH 1/6] mpt fusion - fibre channel target discovery prematurely terminates

[Michael Reed <mdr@sgi.com>]

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 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>