Using NetBSD-7 iscsi initiator to FreeBSD-10.2-RELEASE ctld target fails with check condition, overlapped commands attempted, even though ctld claims that it supports tagged queueing. packet captures available at http://poofygoof.com/~agrier/attic/freebsd_iscsi.cap.bz2 . for comparison, the same client connecting to a smartOS (illumOS/opensolaris) iSCSI target is at http://poofygoof.com/~agrier/attic/smartos_iscsi.cap.bz2 , which works correctly. current workaround is to add a quirk to the NetBSD initiator for the FreeBSD target to disable tagged queuing support. it is expected that this hurts throughput, since by definition it disables opportunities for pipelining.
It supports tagged queueing of commands marked as tagged. For some reason the NetBSD initiator sets the "flags" field of SCSI Command PDU to Untagged (0). Not sure what the SCSI spec says, to be honest, but it might it be an initiator error?
initiator bug is simplest explanation. :) I will follow-up on NetBSD side and see if I can implement a code change there. thanks for the troubleshooting assistance.
Thanks! Please leave a note here when the situation gets resolved.
In http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=51037 Michael van Elst writes: In [NetBSD]-current I did some signficant changes to the iSCSI initiator including how tagging is handled. The first attempt was to mark all requests as tagged and simply ordered but I ignored the actual tag values, this stopped the 'illegal request' errors immediately. Now it passes tags from scsipi to the iSCSI layer which is probably the right thing to do if you support taggging. IMHO the FreeBSD target has an issue in how it handles untagged requests, but I haven't found anything suspicious when looking at the FreeBSD code. So we're back to protocol interpretation regarding handling of overlapping untagged commands (which IllumOS supports), but that could be opened as a new bug if anybody cares. I did a minimal back-port of Michael's tagging changes from NetBSD-current, and believe this bug can be closed.
I agree with Edward that it is an initiator bug. Old SAM-2 specification states: "An untagged task does not include a tag in its I_T_L nexus, thus restricting the number of concurrent untagged tasks in a single task set to one per SCSI initiator port.", that is exactly what CTL enforces. Attempt to send more then one untagged command at a time causes error. If initiator uses untagged commands, that it must execute them one at a time. Latest SAM-5 specification obsoletes untagged tasks completely, so they just should not be used in new implementations.
Closing this, as it really looks like an initiator bug. Please reopen if you disagree. Thanks :-)