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¹s comment on it. >> 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]. 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.
