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, or for this
>     case that the code was handling should iscsiuio general always be
>     up? If we want the retry/timeout tracking, how long should we be
>     waiting for? How long did the problem we were fixing take to resolve
>     itself?
> 
> -- 
> 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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at http://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.

-- 
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