Hi Nicholas, I sent the trace and /var/log/messages off list. This trace is executed with only one command outstanding. Here's what I see from the data: 1. Error occurs on packet 69762 for a write (packet 69751) with Immediate Data = 0x1f70 and Expected Data Transfer Length = 0xf000. 2. Many prior write transactions(782)complete fine with Immediate Data = 0x1f60 and Expected Data transfer Length = 0xf000. 3. Packet 69751 is the first write using Immediate Data = 0x1f70. I will start varying the InitialR2T, ImmediateData, FirstBurstLength, MaxBurstLength and MaxRecvDataSegmentLength keys. No digest testing was performed with the initiator in a Linux system though I did do long duration login/logout tests there with 512 targets. I moved to Windows to do Iometer testing and did not see any issues with no digest. I could not even initialize the drive with both digests enabled. This is what I am using as a test case. Another thing I need to try is doing a data integrity test with digest disabled under Windows. Thanks, -Joe ----- Original Message ----- From: Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> To: jrepac@xxxxxxxxx Cc: target-devel <target-devel@xxxxxxxxxxxxxxx> Sent: Monday, February 13, 2012 3:12 PM Subject: Re: Data Digest Errors On Mon, 2012-02-13 at 13:24 -0800, jrepac@xxxxxxxxx wrote: > Hi Nicholas, > I found a backdoor on the initiator to limit outstanding commands per > session to one. This did not make the data digest error mis-detection > problem go away. However, I was able to rule out the multiple > outstanding "writes" as a possible contributor to the problem. It > also simplified the trace. > > Hi Joe, Ok, thanks for identifying that the issue does not appear to be related to CmdSN window depth. > I a not sure where to proceed further on this. Do you want me to send > you the latest Wireshark trace and /ver/log/messages? > > Sure, please go ahead and send those to me off-list. So I'm now thinking to zero in what values are negotiated during iSCSI login with Emulex HBA offload for InitialR2T, ImmediateData, FirstBurstLength, MaxBurstLength and MaxRecvDataSegmentLength keys to determine if these are some how different between software iSCSI and emulex offload, or if forcing different values has some effect on the target-side data-digest failures you've been encountering. Out of curiosity, have you also been able to reproduce an simular issue using Emulex HBA offload for iSCSI with Linux as well..? --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
