[Patch v2] module-setup: Don't handle iBFT in kdump

[Baoquan He]

There are several kinds of iSCSI mode rhel support currently.
 - Pure hardware iSCSI
 - iBFT iSCSI
 - Pure software iSCSI

Except for the 1st one that firmware takes care of everything to
make it behave like a local disk, both iBFT and pure software iSCSI
mode need pass information to kdump kernel for configuring them
correctly.

Currently kdump takes iBFT mode as a software iSCSI and collects
the related information to set up software iSCSI in 2nd kernel,
though dracut can detect and collect information to set up iBFT
iSCSI of 2nd kernel. This brings up 2 problems:

1) For iBFT mode 2 sessions will be built in 2nd kernel, one is in
iBFT mode, the other is pure software mode. This is because both
kdump and dracut collect iSCSI inforamtion separately for a certain
iBFT mode iSCSI of 1st kernel.

2) These 2 sessions of 2nd kernel for a certain session of 1st kernel
could contain two "ip=xxx" cmdline option. This will cause cmdline
handling error in dracut.

In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
and leave it to dracut. This is what is donw in this patch.

Signed-off-by: Baoquan He 
---
 dracut-module-setup.sh | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index ecf7d3f..aa204f8 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
     return 1
 }

-# No ibft handling yet.
+# Figure out iBFT session according to session type
+is_ibft() {
+    [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
+}
+
 kdump_setup_iscsi_device() {
     local path=$1
     local tgt_name; local tgt_ipaddr;
@@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
         return 1
     fi

+    if is_ibft ${path}; then
+        return
+    fi
+
     tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
     tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")

[Baoquan He]

I thought to add Minfei Huang  as author and his
signed-off-by at the end of log, but git send-email can't send email
with an warning "5.1.1  ... User unknown". So I have
to take this as author.

On 06/29/16 at 10:08am, Baoquan He wrote:
> There are several kinds of iSCSI mode rhel support currently.
> Pure hardware iSCSI
> iBFT iSCSI
> Pure software iSCSI
>
> Except for the 1st one that firmware takes care of everything to
> make it behave like a local disk, both iBFT and pure software iSCSI
> mode need pass information to kdump kernel for configuring them
> correctly.
>
> Currently kdump takes iBFT mode as a software iSCSI and collects
> the related information to set up software iSCSI in 2nd kernel,
> though dracut can detect and collect information to set up iBFT
> iSCSI of 2nd kernel. This brings up 2 problems:
> For iBFT mode 2 sessions will be built in 2nd kernel, one is in
>
> iBFT mode, the other is pure software mode. This is because both
> kdump and dracut collect iSCSI inforamtion separately for a certain
> iBFT mode iSCSI of 1st kernel.
> These 2 sessions of 2nd kernel for a certain session of 1st kernel
>
> could contain two "ip=xxx" cmdline option. This will cause cmdline
> handling error in dracut.
>
> In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> and leave it to dracut. This is what is donw in this patch.
> Signed-off-by: Baoquan He
>
> dracut-module-setup.sh | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index ecf7d3f..aa204f8 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
>      return 1
>  }
>
> -# No ibft handling yet.
> +# Figure out iBFT session according to session type
> +is_ibft() {
> [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
>
> +}
>
> kdump_setup_iscsi_device() {
>      local path=$1
>      local tgt_name; local tgt_ipaddr;
> @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
>          return 1
>      fi
> if is_ibft ${path}; then
>    return
> fi
> tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
>
> -- 
> 2.5.5

[Xunlei Pang]

On 2016/06/28 at 22:08, Baoquan He wrote:
> There are several kinds of iSCSI mode rhel support currently.
> Pure hardware iSCSI
> iBFT iSCSI
> Pure software iSCSI

Since we had the following standard iSCSI naming, how about to use them instead?
- iSCSI HBA (all offload)
- Software iSCSI with iBFT (bnx2i, cxgb3i, cxgb4i)
- Software iSCSI with hybrid (be2iscsi)
- Software initiator based iSCSI
> Except for the 1st one that firmware takes care of everything to
> make it behave like a local disk, both iBFT and pure software iSCSI
> mode need pass information to kdump kernel for configuring them
> correctly.
>
> Currently kdump takes iBFT mode as a software iSCSI and collects
> the related information to set up software iSCSI in 2nd kernel,
> though dracut can detect and collect information to set up iBFT
> iSCSI of 2nd kernel. This brings up 2 problems:
> For iBFT mode 2 sessions will be built in 2nd kernel, one is in
>
> iBFT mode, the other is pure software mode. This is because both
> kdump and dracut collect iSCSI inforamtion separately for a certain

s/inforamtion/information
> iBFT mode iSCSI of 1st kernel.

Which session will be used in such cases? or it will become dysfunctional with the 2 sessions?
> These 2 sessions of 2nd kernel for a certain session of 1st kernel
>
> could contain two "ip=xxx" cmdline option. This will cause cmdline
> handling error in dracut.

Yeah, this is understandable.
> In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> and leave it to dracut. This is what is donw in this patch.

s/donw/done

Regards,
Xunlei
> Signed-off-by: Baoquan He
>
> dracut-module-setup.sh | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index ecf7d3f..aa204f8 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
>      return 1
>  }
>
> -# No ibft handling yet.
> +# Figure out iBFT session according to session type
> +is_ibft() {
> [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
>
> +}
>
> kdump_setup_iscsi_device() {
>      local path=$1
>      local tgt_name; local tgt_ipaddr;
> @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
>          return 1
>      fi
> if is_ibft ${path}; then
>    return
> fi
> tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")

[Baoquan He]

On 06/29/16 at 10:04am, Xunlei Pang wrote:
> On 2016/06/28 at 22:08, Baoquan He wrote:
> > There are several kinds of iSCSI mode rhel support currently.
> > Pure hardware iSCSI
> > iBFT iSCSI
> > Pure software iSCSI
>
> Since we had the following standard iSCSI naming, how about to use them instead?
> iSCSI HBA (all offload)
> Software iSCSI with iBFT (bnx2i, cxgb3i, cxgb4i)
> Software iSCSI with hybrid (be2iscsi)
> Software initiator based iSCSI

Thanks for your comments, Xunlei.

I want to say, right, these are written into supported-kdump-targets.txt
and customers can check them too. However when we discuss in technical
meeting or face to face talking we used to call the name we can remember
easily, like pure hardware iSCSI, ibft iSCSI and pure software iSCSI. I
refer to them in patch log because commit log can only be seen by us,
kdump dev. When we git blame those code or doc we don't understand, we
can catch it by these commit log. This is why I chose to use these
non-standard but easily remembered names.

I am fine if you insist on this, I can change it.
> > Except for the 1st one that firmware takes care of everything to
> > make it behave like a local disk, both iBFT and pure software iSCSI
> > mode need pass information to kdump kernel for configuring them
> > correctly.
> >
> > Currently kdump takes iBFT mode as a software iSCSI and collects
> > the related information to set up software iSCSI in 2nd kernel,
> > though dracut can detect and collect information to set up iBFT
> > iSCSI of 2nd kernel. This brings up 2 problems:
> > For iBFT mode 2 sessions will be built in 2nd kernel, one is in
> >
> > iBFT mode, the other is pure software mode. This is because both
> > kdump and dracut collect iSCSI inforamtion separately for a certain
>
> s/inforamtion/information
> > iBFT mode iSCSI of 1st kernel.
>
> Which session will be used in such cases? or it will become dysfunctional with the 2 sessions?

Sorry, I was wrong here. Checked with Minfei again in mail, there's only
one session. The ibft session is setup earlier, then it won't do it
again when parse pure software iSCSI information passed in. Here
only redundent information is connected and passed to 2nd kernel.
> > These 2 sessions of 2nd kernel for a certain session of 1st kernel
> >
> > could contain two "ip=xxx" cmdline option. This will cause cmdline
> > handling error in dracut.
>
> Yeah, this is understandable.
> > In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> > and leave it to dracut. This is what is donw in this patch.
>
> s/donw/done

Will update this when repost.
> Regards,
> Xunlei
> > Signed-off-by: Baoquan He
> >
> > dracut-module-setup.sh | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index ecf7d3f..aa204f8 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
> >      return 1
> >  }
> >
> > -# No ibft handling yet.
> > +# Figure out iBFT session according to session type
> > +is_ibft() {
> > [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
> >
> > +}
> >
> > kdump_setup_iscsi_device() {
> >      local path=$1
> >      local tgt_name; local tgt_ipaddr;
> > @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
> >          return 1
> >      fi
> > if is_ibft ${path}; then
> >    return
> > fi
> > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> >    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
>
> kexec mailing list
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Baoquan He]

On 06/30/16 at 02:42pm, Baoquan He wrote:
> On 06/29/16 at 10:04am, Xunlei Pang wrote:
> > On 2016/06/28 at 22:08, Baoquan He wrote:
> > > There are several kinds of iSCSI mode rhel support currently.
> > > Pure hardware iSCSI
> > > iBFT iSCSI
> > > Pure software iSCSI
> >
> > Since we had the following standard iSCSI naming, how about to use them instead?
> > iSCSI HBA (all offload)
> > Software iSCSI with iBFT (bnx2i, cxgb3i, cxgb4i)
> > Software iSCSI with hybrid (be2iscsi)
> > Software initiator based iSCSI
>
> Thanks for your comments, Xunlei.
>
> I want to say, right, these are written into supported-kdump-targets.txt
> and customers can check them too. However when we discuss in technical
> meeting or face to face talking we used to call the name we can remember
> easily, like pure hardware iSCSI, ibft iSCSI and pure software iSCSI. I
> refer to them in patch log because commit log can only be seen by us,
> kdump dev. When we git blame those code or doc we don't understand, we
> can catch it by these commit log. This is why I chose to use these
> non-standard but easily remembered names.
>
> I am fine if you insist on this, I can change it.
> > > Except for the 1st one that firmware takes care of everything to
> > > make it behave like a local disk, both iBFT and pure software iSCSI
> > > mode need pass information to kdump kernel for configuring them
> > > correctly.
> > >
> > > Currently kdump takes iBFT mode as a software iSCSI and collects
> > > the related information to set up software iSCSI in 2nd kernel,
> > > though dracut can detect and collect information to set up iBFT
> > > iSCSI of 2nd kernel. This brings up 2 problems:
> > > For iBFT mode 2 sessions will be built in 2nd kernel, one is in
> > >
> > > iBFT mode, the other is pure software mode. This is because both
> > > kdump and dracut collect iSCSI inforamtion separately for a certain
> >
> > s/inforamtion/information
> > > iBFT mode iSCSI of 1st kernel.
> >
> > Which session will be used in such cases? or it will become dysfunctional with the 2 sessions?
>
> Sorry, I was wrong here. Checked with Minfei again in mail, there's only
> one session. The ibft session is setup earlier, then it won't do it
> again when parse pure software iSCSI information passed in. Here
> only redundent information is connected and passed to 2nd kernel.

~collected, typo
> > > These 2 sessions of 2nd kernel for a certain session of 1st kernel
> > >
> > > could contain two "ip=xxx" cmdline option. This will cause cmdline
> > > handling error in dracut.
> >
> > Yeah, this is understandable.
> > > In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> > > and leave it to dracut. This is what is donw in this patch.
> >
> > s/donw/done
>
> Will update this when repost.
> > Regards,
> > Xunlei
> > > Signed-off-by: Baoquan He
> > >
> > > dracut-module-setup.sh | 10 +++++++++-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > > index ecf7d3f..aa204f8 100755
> > > --- a/dracut-module-setup.sh
> > > +++ b/dracut-module-setup.sh
> > > @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
> > >      return 1
> > >  }
> > >
> > > -# No ibft handling yet.
> > > +# Figure out iBFT session according to session type
> > > +is_ibft() {
> > > [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
> > >
> > > +}
> > >
> > > kdump_setup_iscsi_device() {
> > >      local path=$1
> > >      local tgt_name; local tgt_ipaddr;
> > > @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
> > >          return 1
> > >      fi
> > > if is_ibft ${path}; then
> > >    return
> > > fi
> > > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> > >    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
> >
> > kexec mailing list
> > [e-mail]
> > https://lists.fedoraproject.org/admin/lists/[e-mail]
>
> kexec mailing list
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Xunlei Pang]

On 2016/06/30 at 02:42, Baoquan He wrote:
> On 06/29/16 at 10:04am, Xunlei Pang wrote:
> > On 2016/06/28 at 22:08, Baoquan He wrote:
> > > There are several kinds of iSCSI mode rhel support currently.
> > > Pure hardware iSCSI
> > > iBFT iSCSI
> > > Pure software iSCSI
> >
> > Since we had the following standard iSCSI naming, how about to use them instead?
> > iSCSI HBA (all offload)
> > Software iSCSI with iBFT (bnx2i, cxgb3i, cxgb4i)
> > Software iSCSI with hybrid (be2iscsi)
> > Software initiator based iSCSI
>
> Thanks for your comments, Xunlei.
>
> I want to say, right, these are written into supported-kdump-targets.txt
> and customers can check them too. However when we discuss in technical
> meeting or face to face talking we used to call the name we can remember
> easily, like pure hardware iSCSI, ibft iSCSI and pure software iSCSI. I
> refer to them in patch log because commit log can only be seen by us,
> kdump dev. When we git blame those code or doc we don't understand, we
> can catch it by these commit log. This is why I chose to use these
> non-standard but easily remembered names.
>
> I am fine if you insist on this, I can change it.

Hmm, that's ok for internal discussion.
> > > Except for the 1st one that firmware takes care of everything to
> > > make it behave like a local disk, both iBFT and pure software iSCSI
> > > mode need pass information to kdump kernel for configuring them
> > > correctly.
> > >
> > > Currently kdump takes iBFT mode as a software iSCSI and collects
> > > the related information to set up software iSCSI in 2nd kernel,
> > > though dracut can detect and collect information to set up iBFT
> > > iSCSI of 2nd kernel. This brings up 2 problems:
> > > For iBFT mode 2 sessions will be built in 2nd kernel, one is in
> > >
> > > iBFT mode, the other is pure software mode. This is because both
> > > kdump and dracut collect iSCSI inforamtion separately for a certain
> >
> > s/inforamtion/information
> > > iBFT mode iSCSI of 1st kernel.
> >
> > Which session will be used in such cases? or it will become dysfunctional with the 2 sessions?
>
> Sorry, I was wrong here. Checked with Minfei again in mail, there's only
> one session. The ibft session is setup earlier, then it won't do it
> again when parse pure software iSCSI information passed in. Here
> only redundent information is connected and passed to 2nd kernel.

So, the only problem doing this way is 2).
Thanks for the explanation.

Regards,
Xunlei
> > > These 2 sessions of 2nd kernel for a certain session of 1st kernel
> > >
> > > could contain two "ip=xxx" cmdline option. This will cause cmdline
> > > handling error in dracut.
> >
> > Yeah, this is understandable.
> > > In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> > > and leave it to dracut. This is what is donw in this patch.
> >
> > s/donw/done
>
> Will update this when repost.
> > Regards,
> > Xunlei
> > > Signed-off-by: Baoquan He
> > >
> > > dracut-module-setup.sh | 10 +++++++++-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > > index ecf7d3f..aa204f8 100755
> > > --- a/dracut-module-setup.sh
> > > +++ b/dracut-module-setup.sh
> > > @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
> > >      return 1
> > >  }
> > >
> > > -# No ibft handling yet.
> > > +# Figure out iBFT session according to session type
> > > +is_ibft() {
> > > [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
> > >
> > > +}
> > >
> > > kdump_setup_iscsi_device() {
> > >      local path=$1
> > >      local tgt_name; local tgt_ipaddr;
> > > @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
> > >          return 1
> > >      fi
> > > if is_ibft ${path}; then
> > >    return
> > > fi
> > > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> > >    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
> >
> > kexec mailing list
> > [e-mail]
> > https://lists.fedoraproject.org/admin/lists/[e-mail]

[Patch v3] module-setup: Don't handle iBFT in kdump

[Baoquan He]

There are several kinds of iSCSI mode rhel support currently.
 - Pure hardware iSCSI
 - iBFT iSCSI
 - Pure software iSCSI

Except for the 1st one that firmware takes care of everything to
make it behave like a local disk, both iBFT and pure software iSCSI
mode need pass information to kdump kernel for configuring them
correctly.

Currently kdump takes iBFT mode as a software iSCSI and collects
the related information to set up software iSCSI in 2nd kernel,
though dracut can detect and collect information to set up iBFT
iSCSI of 2nd kernel. This brings up 2 problems:

1) Redundent information about the related iSCSI is collected. One
is done by kdump, the other is from dracut.

2) These 2 sessions of 2nd kernel for a certain session of 1st kernel
could contain two "ip=xxx" cmdline option. This will cause cmdline
handling error in dracut.

The 1st one is not critical while the 2nd is. In order to avoid above
2 problems, kdump need detect iBFT mode iSCSI and leave it to dracut.
This is what is done in this patch.

Signed-off-by: Baoquan He 
---
 dracut-module-setup.sh | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index ecf7d3f..aa204f8 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
     return 1
 }

-# No ibft handling yet.
+# Figure out iBFT session according to session type
+is_ibft() {
+    [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
+}
+
 kdump_setup_iscsi_device() {
     local path=$1
     local tgt_name; local tgt_ipaddr;
@@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
         return 1
     fi

+    if is_ibft ${path}; then
+        return
+    fi
+
     tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
     tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")

[Patch v3] module-setup: Don't handle iBFT in kdump

[Dave Young]

On 07/01/16 at 10:34am, Baoquan He wrote:
> There are several kinds of iSCSI mode rhel support currently.
> Pure hardware iSCSI
> iBFT iSCSI
> Pure software iSCSI
>
> Except for the 1st one that firmware takes care of everything to
> make it behave like a local disk, both iBFT and pure software iSCSI
> mode need pass information to kdump kernel for configuring them
> correctly.
>
> Currently kdump takes iBFT mode as a software iSCSI and collects
> the related information to set up software iSCSI in 2nd kernel,
> though dracut can detect and collect information to set up iBFT
> iSCSI of 2nd kernel. This brings up 2 problems:
> Redundent information about the related iSCSI is collected. One
>
> is done by kdump, the other is from dracut.
> These 2 sessions of 2nd kernel for a certain session of 1st kernel
>
> could contain two "ip=xxx" cmdline option. This will cause cmdline
> handling error in dracut.
>
> The 1st one is not critical while the 2nd is. In order to avoid above
> 2 problems, kdump need detect iBFT mode iSCSI and leave it to dracut.
> This is what is done in this patch.
> Signed-off-by: Baoquan He
>
> dracut-module-setup.sh | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index ecf7d3f..aa204f8 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
>      return 1
>  }
>
> -# No ibft handling yet.
> +# Figure out iBFT session according to session type
> +is_ibft() {
> [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
>
> +}
>
> kdump_setup_iscsi_device() {
>      local path=$1
>      local tgt_name; local tgt_ipaddr;
> @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
>          return 1
>      fi
> if is_ibft ${path}; then
>    return
> fi
> tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")

Hmm, I did not notice the new version. What is the difference between this
one and V2?

Thanks
Dave

[Patch v3] module-setup: Don't handle iBFT in kdump

[Xunlei Pang]

On 2016/07/06 at 08:43, Dave Young wrote:
> On 07/01/16 at 10:34am, Baoquan He wrote:
> > There are several kinds of iSCSI mode rhel support currently.
> > Pure hardware iSCSI
> > iBFT iSCSI
> > Pure software iSCSI
> >
> > Except for the 1st one that firmware takes care of everything to
> > make it behave like a local disk, both iBFT and pure software iSCSI
> > mode need pass information to kdump kernel for configuring them
> > correctly.
> >
> > Currently kdump takes iBFT mode as a software iSCSI and collects
> > the related information to set up software iSCSI in 2nd kernel,
> > though dracut can detect and collect information to set up iBFT
> > iSCSI of 2nd kernel. This brings up 2 problems:
> > Redundent information about the related iSCSI is collected. One
> >
> > is done by kdump, the other is from dracut.
> > These 2 sessions of 2nd kernel for a certain session of 1st kernel
> >
> > could contain two "ip=xxx" cmdline option. This will cause cmdline
> > handling error in dracut.
> >
> > The 1st one is not critical while the 2nd is. In order to avoid above
> > 2 problems, kdump need detect iBFT mode iSCSI and leave it to dracut.
> > This is what is done in this patch.
> > Signed-off-by: Baoquan He
> >
> > dracut-module-setup.sh | 10 +++++++++-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index ecf7d3f..aa204f8 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
> >      return 1
> >  }
> >
> > -# No ibft handling yet.
> > +# Figure out iBFT session according to session type
> > +is_ibft() {
> > [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
> >
> > +}
> >
> > kdump_setup_iscsi_device() {
> >      local path=$1
> >      local tgt_name; local tgt_ipaddr;
> > @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
> >          return 1
> >      fi
> > if is_ibft ${path}; then
> >    return
> > fi
> > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> >    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
>
> Hmm, I did not notice the new version. What is the difference between this
> one and V2?

V3 was updated with an improved changelog.

According to our good test results:
Acked-by: Xunlei Pang
> Thanks
> Dave

[Dave Young]

On 06/29/16 at 10:08am, Baoquan He wrote:
> There are several kinds of iSCSI mode rhel support currently.
> Pure hardware iSCSI
> iBFT iSCSI
> Pure software iSCSI
>
> Except for the 1st one that firmware takes care of everything to
> make it behave like a local disk, both iBFT and pure software iSCSI
> mode need pass information to kdump kernel for configuring them
> correctly.
>
> Currently kdump takes iBFT mode as a software iSCSI and collects
> the related information to set up software iSCSI in 2nd kernel,
> though dracut can detect and collect information to set up iBFT
> iSCSI of 2nd kernel. This brings up 2 problems:
> For iBFT mode 2 sessions will be built in 2nd kernel, one is in
>
> iBFT mode, the other is pure software mode. This is because both
> kdump and dracut collect iSCSI inforamtion separately for a certain
> iBFT mode iSCSI of 1st kernel.
> These 2 sessions of 2nd kernel for a certain session of 1st kernel
>
> could contain two "ip=xxx" cmdline option. This will cause cmdline
> handling error in dracut.
>
> In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> and leave it to dracut. This is what is donw in this patch.
> Signed-off-by: Baoquan He
>
> dracut-module-setup.sh | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index ecf7d3f..aa204f8 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
>      return 1
>  }
>
> -# No ibft handling yet.
> +# Figure out iBFT session according to session type
> +is_ibft() {
> [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
>
> +}
>
> kdump_setup_iscsi_device() {
>      local path=$1
>      local tgt_name; local tgt_ipaddr;
> @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
>          return 1
>      fi
> if is_ibft ${path}; then
>    return
> fi
> tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
>    tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
>
> -- 
> 2.5.5
> _______________________________________________
> kexec mailing list
> [e-mail]
> https://lists.fedoraproject.org/admin/lists/[e-mail]

Acked-by: Dave Young

Thanks
Dave