In 1st kernel, the iscsi device could be both software or hardware based. But we only use software iscsi in 2nd kernel. This is fine for software iscsi as it's consistent with 1st kernel. However kdump bringing up hardware iscsi in software mode could lead conflicts with dracut bringing up logic, depending on the configuration.
If boot disk is hardware iscsi, we should still use hardware iscsi in 2nd kernel. In this case, dracut will bring up the device like it does for normal boot. kdump don't need to do extra work to configure software iscsi.
Signed-off-by: WANG Chao chaowang@redhat.com --- 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 d65c8c0..6f6648d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -412,7 +412,11 @@ kdump_get_iscsi_initiator() { return 1 }
-# No ibft handling yet. +# Figure out if the iscsi session is based on iBFT or firmware +kdump_handle_hw_iscsi() { + [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ] +} + kdump_setup_iscsi_device() { local path=$1 local tgt_name; local tgt_ipaddr; @@ -435,6 +439,10 @@ kdump_setup_iscsi_device() { return 1 fi
+ if kdump_handle_hw_iscsi ${path}; then + return 0 + fi + tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
On 01/04/15 at 06:55pm, WANG Chao wrote:
In 1st kernel, the iscsi device could be both software or hardware based. But we only use software iscsi in 2nd kernel. This is fine for software iscsi as it's consistent with 1st kernel. However kdump bringing up hardware iscsi in software mode could lead conflicts with dracut bringing up logic, depending on the configuration.
If boot disk is hardware iscsi, we should still use hardware iscsi in 2nd kernel. In this case, dracut will bring up the device like it does for normal boot. kdump don't need to do extra work to configure software iscsi.
I just go through the hw iscsi patch series, found this patch is much different with v2. Then talked to Chao face to face, he told me what this patch is trying to cover:
hw iscsi --> rd.iscsi.firmware=1 need be specified in cmdline of 1st kernel / HBA (bios) \ ip=ibft need be specified in cmdline. But if no rd.iscsi.firmware=1, only bring up that NIC
For above 2 cases, we did nothing in kdump shell since it's enough to inherit the kernel cmdline of 1st kernel. And both of them are only concerned with the case which boot disk is dump target.
HBA -> /dev/sdx
For above case, the hw firmare is very smart and can take care of anything. When system bootup if will appear automatically. This works for kdump kernel too.
For the rest of cases, this patch doesn't cover. And Chao plan to add it later when user has new hardware and require it in new bugs.
Am I correct on above conclusion about what we have talked? If yes, it will be good if they are put in patch log as well, can help people understand the status of hw iscsi support and what this patch is handling and what we still need to track and support later.
And also why we only cover this cases and why we can't take care of all of them should be put in log too.
Thanks Baoquan
Signed-off-by: WANG Chao chaowang@redhat.com
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 d65c8c0..6f6648d 100755 --- a/dracut-module-setup.sh +++ b/dracut-module-setup.sh @@ -412,7 +412,11 @@ kdump_get_iscsi_initiator() { return 1 }
-# No ibft handling yet. +# Figure out if the iscsi session is based on iBFT or firmware +kdump_handle_hw_iscsi() {
- [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")" = fw ]
+}
kdump_setup_iscsi_device() { local path=$1 local tgt_name; local tgt_ipaddr; @@ -435,6 +439,10 @@ kdump_setup_iscsi_device() { return 1 fi
- if kdump_handle_hw_iscsi ${path}; then
return 0
- fi
- tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name") tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path} "node.conn[0].address")
-- 2.1.0
kexec mailing list kexec@lists.fedoraproject.org https://lists.fedoraproject.org/mailman/listinfo/kexec