Hi Himanshu,
a common customer figured that the current qla2xxx code wouldn't work
with direct-attached FCP SCSI devices.
I've made a quick hack to re-establish operations:
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 70c7bfa2d73c..fd4043b551a2 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4863,7 +4863,8 @@ void qla24xx_create_new_sess(struct scsi_qla_host
*vha, struct qla_work_evt *e)
if (e->u.new_sess.fc4_type & FS_FC4TYPE_FCP)
fcport->fc4_type = FC4_TYPE_FCP_SCSI;
- if (e->u.new_sess.fc4_type & FS_FC4TYPE_NVME) {
+ if (vha->flags.nvme_enabled &&
+ e->u.new_sess.fc4_type & FS_FC4TYPE_NVME) {
fcport->fc4_type = FC4_TYPE_OTHER;
fcport->fc4f_nvme = FC4_TYPE_NVME;
}
but this will only work if 'ql2xnvmeenable=0' is set.
The _actual_ fix will be to check the PRLI response so see which FC4
type has been successfully logged in.
And I'm not sure what would be the correct way of handling this; FC-LS3
is silent as to what should happen if several FC4 types are specified.
It looks as if it were possible to return LS_ACC even though only one of
the specified FC4 types have been logged in.
So I guess we need to revalidate the response, but I can't see how I
could get access to that ...
Of course, that will leave us none the wiser if _both_ FC4 types are
logged in; I haven't seen any indication that the driver can handle
dual-protocol target ports. But then I haven't seen any targets
providing dual-protocol ports for direct attach, so it's not an urgent
issue.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
