On 08/01/2014 05:59 AM, Vikas Chaudhary wrote:
> 
> 
> On 31/07/14 11:43 pm, "Mike Christie" <[email protected]> wrote:
> 
>> Was waiting on response from Qlogic/Broadcom.
>>
>>
>>
>> On 07/31/2014 01:19 AM, Roi Dayan wrote:
>>> Hi Mike,
>>>
>>> Is there a new patch?
>>> I'm checking I didn't miss it.
>>>
>>> We did tests with the current patch for now and it worked ok.
>>>
>>> Thanks,
>>> Roi
>>>
>>>
>>> On Friday, July 25, 2014 5:17:44 PM UTC+3, Mike Christie wrote:
>>>
>>>
>>>     On Jul 24, 2014, at 4:46 PM, Eddie Wai <[email protected]
>>>     <javascript:>> wrote:
>>>
>>>     > On Thu, 2014-07-24 at 12:50 -0500, Mike Christie wrote:
>>>     >> Hey Roi, Vikas and Eddie,
>>>     >>
>>>     >> The attached patch fixes the issue Roi reported where the
>>>     login_timer
>>>     >> was not deleted and so we end up with a infinite loop. Roi, could
>>>     you
>>>     >> test your failure case?
>>>     >>
>>>     >> Vikas and Eddie, I ccd you guys because it modifies the bnx2i
>>>     iscsiuio
>>>     >> code. There was a issue where iscsiuio was not ready (or the host
>>>     was
>>>     >> not yet ready) and so iscsid would poll iscsiuio for a second or
>>>     two and
>>>     >> it would use the login_timer as a watchdog. A couple weeks ago we
>>>     hit a
>>>     >> issue with be2iscsi where the host was not ready to go so iscsid
>>> got
>>>     >> code to poll the iscsi/scsi_host. So this patch removes the
>>> iscsiuio
>>>     >> login_timer use and then also has it use this new common setup
>>>     polling.
>>>     >>
>>>     > For the iscsiuio related changes, it looks like it will actually
>>>     change
>>>     > the iscsid to iscsiuio re-engagement behavior after the initial 3
>>>     failed
>>>     > communication attempts.  The old code would delay and re-schedule
>>> the
>>>     > login timer actor to retry the iscsiuio communication while the
>>>     new code
>>>     > would simply failed the entire login attempt.
>>>
>>>     Ah ok, I misread the intention of the code. Let me rework my patch.
>>>
>>>     Should there be a retry limit or timeout to control how long we
>>>     retry? 
> 
>>> I was thinking that there could be cases where iscsiuio could
>>>     not respond and we would want to give up eventually,
> 
> We have tested this patch for bnx2i and it is working fine.
> I agree with your assessment above, but will wait for Eddieé›¶ comment on
> it.
> 

Eddie, let me know how long we should wait for before giving up and I
will adjust the patch accordingly.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to