Ping for the Mellanox folks.. Can someone please take a look at the WRITE_SAME logic on the ESX initiator side that is triggering the bug that Moussa was/is hitting..? Based upon the details below, it's clear that it's something specific to the ESX initiator side, as we've been able to verify WRITE_SAME works as expected with open-iscsi + iser, along with existing ESX iscsi + FC initiators. It would be nice to finally the last remaining VAAI primitive working with the in-box ESX iser initiator. ;) Thank you, --nab On Fri, 2014-05-23 at 12:03 -0700, Nicholas A. Bellinger wrote: > On Thu, 2014-05-22 at 17:25 -0700, Nicholas A. Bellinger wrote: > > Hi Moussa, > > > > On Thu, 2014-05-22 at 21:35 +0000, Moussa Ba (moussaba) wrote: > > > > <SNIP> > > > > > > The question I have is where does this information belong and how can > > > > > one debug these issues... > > > > > > > > > > > > > FYI, these VAAI primitives can also be disabled target side with device > > > > attributes: > > > > > > > > emulate_caw=0 > > > > emulate_3pc=0 > > > > max_write_same_len=0 > > > > > > > > To debug, please try ESX host settings Init=0 + Move=1 + Locking=1 to > > > > see if it's specific to WRITE_SAME, and separately if COMPARE_AND_WRITE > > > > traffic can also trigger the bug.. > > > > > > Setting Init=0, Move=1 and Locking=1 does not create the time out > > > issue. So so far it seems the issues is specific to WRITE_SAME. I > > > will > > > > > > > Great, thanks for the update. > > > > > > > > > > Also, what do the negotiated ImmediateData + InitialR2T parameter > > > > settings look like..? > > > > > > Both are set to yes. I am reading these off of /sys/kernel/config/.../iqn..../param/ > > > > > > > > > > OK, I'll verify WRITE_SAME works as expected with the Linux iSER > > initiator, and from there it should be clear if it's a bug specific to > > ESX iSER initiator code. > > > > Ok, I've verified that WRITE_SAME works as expected using open-iscsi w/ > iSER enabled with both ImmediateData=Yes + ImmediateData=No parameter > settings. (Output included below..) > > At this point, it looks pretty clear that it's an ESX iSER initiator bug > specific to WRITE_SAME opcodes. > > Mellanox folks, can you please have a look at this..? > > --nab > > # hexdump test > 0000000 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000010 0000 0000 0000 0000 0000 0000 0000 0000 > > # sg_write_same --lba=0 --num=8 --in=test --verbose /dev/sdj > # dd if=/dev/sdj of=foo bs=512 count=16 ; hexdump foo > 16+0 records in > 16+0 records out > 8192 bytes (8.2 kB) copied, 0.0197071 s, 416 kB/s > 0000000 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000010 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000200 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000210 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000400 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000410 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000600 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000610 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000800 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000810 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000a00 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000a10 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000c00 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000c10 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0000e00 bbaa ddcc ffee 2211 4433 6655 8877 0099 > 0000e10 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0002000 > > -- > 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 -- 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
