On Mon, 2012-02-06 at 07:25 -0800, jrepac@xxxxxxxxx wrote: > I noted something interesting with the digest error problem noted > over the past two months with the Emulex initiator and the target. > It seems that problem occurs just after the target sends out a sequence > of multiple tightly spaced R2Ts for outstanding write commands. The > problem occurs while simply trying to initialize or format the drive > with the MS iSCSI initiator (using the Emulex adapter instance). Errors > are reported in /var/log/messages as data digest failures but the wireshark > trace shows the digest is actually good. The MS drive initialization > completes fine when both data and header digest are disabled. > Hi Joe, Thanks for continuing to look into this issue. > This problem only seems to occur when a group of R2T's are sent > out with <20us between PDUs. So thinking about this a bit more, you may want to verify that the MaxOutstandingR2T value is being negotiated to '1' during iSCSI session login. Note that mainline iscsi_target_mod code does support >1 operation, but I'm pretty sure the MSFT login logic should be negotiating MaxOutstandingR2T=1.. Definitely worth checking at this point. > I did four trace captures on this last night and the behavior seems to be consistent. > The magic number so far is three R2Ts. Nicholas fixed a list corruption issue (noted below) > that was occurring when the first mis-detected digest error report. However, the mis-detected > digest error remains. It seems like data for another outstanding write command (released by > one of the R2Ts) is interfering with a digest calculation in progress. > > Can someone familiar with this area of the take a look at this? I plan to cut the > queue depth on the target to 1 today to see if the problem goes away. > I assume you mean iSCSI CmdSN session depth here, yes..? By default this value is currently set to 16, and can be changed via default_queue_depth (for TPG demo-mode operation) or via queue_depth attribute for explict iSCSI initiator NodeACLs. --nab -- 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
