Hi Witold,
On Sat, 2013-11-23 at 08:07 +0100, Witold Bazakbal wrote:
>
> I have problem with booting DELL r620 from LIO-Target. DELL server have NIC Broadcom 57800. I try to boot it from
> fedora 19 with lio-target.
>
> Linux nas.localhost 3.11.8-200.fc19.x86_64 #1 SMP Wed Nov 13 16:29:59 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>
> lio config :
>
> o- / ......................................................................................................................... [...]
> o- backstores .............................................................................................................. [...]
> | o- block .................................................................................................. [Storage Objects: 0]
> | o- fileio ................................................................................................. [Storage Objects: 1]
> | | o- vol0 ..................................................................... [/mnt/shares/vol0 (9.3GiB) write-back activated]
> | o- pscsi .................................................................................................. [Storage Objects: 0]
> | o- ramdisk ................................................................................................ [Storage Objects: 0]
> o- iscsi ............................................................................................................ [Targets: 1]
> | o- iqn.1999-01.xx.xx:boot1 ....................................................................................... [TPGs: 1]
> | o- tpg1 ............................................................................................... [no-gen-acls, no-auth]
> | o- acls .......................................................................................................... [ACLs: 1]
> | | o- iqn.1999-01.local.int:server.2.nic.2 ................................................................. [Mapped LUNs: 1]
> | | o- mapped_lun0 ................................................................................. [lun0 fileio/vol0 (rw)]
> | o- luns .......................................................................................................... [LUNs: 1]
> | | o- lun0 ................................................................................. [fileio/vol0 (/mnt/shares/vol0)]
> | o- portals .................................................................................................... [Portals: 1]
> | o- 192.168.xx.xx:3260 .............................................................................................. [OK]
> o- loopback ......................................................................................................... [Targets: 0]
> o- vhost ............................................................................................................ [Targets: 0]
>
> dmesg :
>
> [23733.006030] ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE set when Expected Data Transfer Length is 0 for CDB: 0x00. Bad iSCSI Initiator.
> [24873.892031] ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE set when Expected Data Transfer Length is 0 for CDB: 0x00. Bad iSCSI Initiator.
>
So the firmware here is setting the ISCSI_FLAG_CMD_READ bit for
TEST_UNIT_READ (CDB: 0x00), when no data payload transfer is occurring.
Looking at this again, it's not illegal to do this according to RFC, so
I've gone ahead and removed the CDB specific checks to always handle
this particular case by simply fixing up the incorrect flag bits.
The following patch should get you up and running. Please let me know
when your able to boot, and then I'll put this patch into the
for-3.13-rc fixes queue.
Thanks for reporting!
--nab
diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index d70e911..02182ab 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -823,24 +823,22 @@ int iscsit_setup_scsi_cmd(struct iscsi_conn *conn, struct iscsi_cmd *cmd,
if (((hdr->flags & ISCSI_FLAG_CMD_READ) ||
(hdr->flags & ISCSI_FLAG_CMD_WRITE)) && !hdr->data_length) {
/*
- * Vmware ESX v3.0 uses a modified Cisco Initiator (v3.4.2)
- * that adds support for RESERVE/RELEASE. There is a bug
- * add with this new functionality that sets R/W bits when
- * neither CDB carries any READ or WRITE datapayloads.
+ * From RFC-3720 Section 10.3.1:
+ *
+ * "Either or both of R and W MAY be 1 when either the
+ * Expected Data Transfer Length and/or Bidirectional Read
+ * Expected Data Transfer Length are 0"
+ *
+ * For this case, go ahead and clear the unnecssary bits
+ * to avoid any confusion with ->data_direction.
*/
- if ((hdr->cdb[0] == 0x16) || (hdr->cdb[0] == 0x17)) {
- hdr->flags &= ~ISCSI_FLAG_CMD_READ;
- hdr->flags &= ~ISCSI_FLAG_CMD_WRITE;
- goto done;
- }
+ hdr->flags &= ~ISCSI_FLAG_CMD_READ;
+ hdr->flags &= ~ISCSI_FLAG_CMD_WRITE;
- pr_err("ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE"
+ pr_warn("ISCSI_FLAG_CMD_READ or ISCSI_FLAG_CMD_WRITE"
" set when Expected Data Transfer Length is 0 for"
- " CDB: 0x%02x. Bad iSCSI Initiator.\n", hdr->cdb[0]);
- return iscsit_add_reject_cmd(cmd,
- ISCSI_REASON_BOOKMARK_INVALID, buf);
+ " CDB: 0x%02x, Fixing up flags\n", hdr->cdb[0]);
}
-done:
if (!(hdr->flags & ISCSI_FLAG_CMD_READ) &&
!(hdr->flags & ISCSI_FLAG_CMD_WRITE) && (hdr->data_length != 0)) {
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
