public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
* Re: Different ISCSI behavior when 2 attempts are added
@ 2017-10-09 14:51 Karunakar P
  2017-10-10  3:00 ` Wu, Jiaxin
  0 siblings, 1 reply; 4+ messages in thread
From: Karunakar P @ 2017-10-09 14:51 UTC (permalink / raw)
  To: 'edk2-devel@lists.01.org'
  Cc: Wu, Jiaxin, Ye, Ting, 'Fu,  Siyuan'

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure ----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist



1.       Case1 & Case3 looks fine as 1st valid attempt connected

2.       But Case2 & Case4 looks bit different, 1St attempt was valid but connection success with 2nd attempt

3.       As we found that IScsiIp4 Driver Binding Start is getting call first and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Different ISCSI behavior when 2 attempts are added
  2017-10-09 14:51 Different ISCSI behavior when 2 attempts are added Karunakar P
@ 2017-10-10  3:00 ` Wu, Jiaxin
  2017-10-10  3:08   ` Ye, Ting
  0 siblings, 1 reply; 4+ messages in thread
From: Wu, Jiaxin @ 2017-10-10  3:00 UTC (permalink / raw)
  To: Karunakar P, 'edk2-devel@lists.01.org'; +Cc: Ye, Ting, Fu, Siyuan

Hi Karunakar,

I think it's not the bug according the current  iSCSI implementation that the first login session will be selected while others are aborted directly. Here, IP4 is the first login session.

I didn't find any state that the first attempt should be connected. Ting and Siyuan, If anything wrong, please correct me.

Thanks,
Jiaxin

From: Karunakar P [mailto:karunakarp@amiindia.co.in]
Sent: Monday, October 9, 2017 10:52 PM
To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>
Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
Subject: Re: Different ISCSI behavior when 2 attempts are added

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure ----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist



1.       Case1 & Case3 looks fine as 1st valid attempt connected

2.       But Case2 & Case4 looks bit different, 1St attempt was valid but connection success with 2nd attempt

3.       As we found that IScsiIp4 Driver Binding Start is getting call first and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Different ISCSI behavior when 2 attempts are added
  2017-10-10  3:00 ` Wu, Jiaxin
@ 2017-10-10  3:08   ` Ye, Ting
  2017-10-10  3:26     ` Karunakar P
  0 siblings, 1 reply; 4+ messages in thread
From: Ye, Ting @ 2017-10-10  3:08 UTC (permalink / raw)
  To: Wu, Jiaxin, Karunakar P, 'edk2-devel@lists.01.org'; +Cc: Fu, Siyuan

Yes, I agree that it is the implementation's choice. If you need Attempt 1 in Case 2&4, try to update "Enabled" to "Enabled for MPIO".

Thanks,
Ting Ye

From: Wu, Jiaxin
Sent: Tuesday, October 10, 2017 11:01 AM
To: Karunakar P <karunakarp@amiindia.co.in>; 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org>
Cc: Ye, Ting <ting.ye@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>
Subject: RE: Different ISCSI behavior when 2 attempts are added

Hi Karunakar,

I think it's not the bug according the current  iSCSI implementation that the first login session will be selected while others are aborted directly. Here, IP4 is the first login session.

I didn't find any state that the first attempt should be connected. Ting and Siyuan, If anything wrong, please correct me.

Thanks,
Jiaxin

From: Karunakar P [mailto:karunakarp@amiindia.co.in]
Sent: Monday, October 9, 2017 10:52 PM
To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>; Ye, Ting <ting.ye@intel.com<mailto:ting.ye@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>
Subject: Re: Different ISCSI behavior when 2 attempts are added

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure ----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist



1.       Case1 & Case3 looks fine as 1st valid attempt connected

2.       But Case2 & Case4 looks bit different, 1St attempt was valid but connection success with 2nd attempt

3.       As we found that IScsiIp4 Driver Binding Start is getting call first and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Different ISCSI behavior when 2 attempts are added
  2017-10-10  3:08   ` Ye, Ting
@ 2017-10-10  3:26     ` Karunakar P
  0 siblings, 0 replies; 4+ messages in thread
From: Karunakar P @ 2017-10-10  3:26 UTC (permalink / raw)
  To: 'Ye, Ting', Wu, Jiaxin, 'edk2-devel@lists.01.org'
  Cc: Fu, Siyuan

Will try with Updating to "Enabled for MPIO".

Thanks for your great support,
Karunakar

From: Ye, Ting [mailto:ting.ye@intel.com]
Sent: Tuesday, October 10, 2017 8:39 AM
To: Wu, Jiaxin; Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan
Subject: RE: Different ISCSI behavior when 2 attempts are added

Yes, I agree that it is the implementation's choice. If you need Attempt 1 in Case 2&4, try to update "Enabled" to "Enabled for MPIO".

Thanks,
Ting Ye

From: Wu, Jiaxin
Sent: Tuesday, October 10, 2017 11:01 AM
To: Karunakar P <karunakarp@amiindia.co.in<mailto:karunakarp@amiindia.co.in>>; 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Ye, Ting <ting.ye@intel.com<mailto:ting.ye@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>
Subject: RE: Different ISCSI behavior when 2 attempts are added

Hi Karunakar,

I think it's not the bug according the current  iSCSI implementation that the first login session will be selected while others are aborted directly. Here, IP4 is the first login session.

I didn't find any state that the first attempt should be connected. Ting and Siyuan, If anything wrong, please correct me.

Thanks,
Jiaxin

From: Karunakar P [mailto:karunakarp@amiindia.co.in]
Sent: Monday, October 9, 2017 10:52 PM
To: 'edk2-devel@lists.01.org' <edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>; Ye, Ting <ting.ye@intel.com<mailto:ting.ye@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>
Subject: Re: Different ISCSI behavior when 2 attempts are added

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure ----Enabled(Initiator DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but session does not exist



1.       Case1 & Case3 looks fine as 1st valid attempt connected

2.       But Case2 & Case4 looks bit different, 1St attempt was valid but connection success with 2nd attempt

3.       As we found that IScsiIp4 Driver Binding Start is getting call first and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-10-10  3:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-10-09 14:51 Different ISCSI behavior when 2 attempts are added Karunakar P
2017-10-10  3:00 ` Wu, Jiaxin
2017-10-10  3:08   ` Ye, Ting
2017-10-10  3:26     ` Karunakar P

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox