On Sun, 2016-02-28 at 00:31 -0500, DAVID S wrote: > Hi Nicholas, thanks for the response. > (Re-adding target-devel CC') > So just to clarify, do I need to recompile the kernel AND disable the > ATS heartbeat to fix this issue, or is the bug only encountered when > ATS heartbeat is enabled? > My understanding is ATS heartbeat for VMFS-5 mounts is recommended to be disabled for all 5.5u2+ hosts connecting to VAAI ATS enabled targets, unless emulate_caw=0 has not already disabled VAAI ATS SCSI level feature bit support all-together from LIO configfs. According to VMWare's -kb, it's enabling ATS heartbeat by default with all VMFS-5 mounts, and disabling ATS heartbeat by default for all VMFS-3 mounts. > I was running on kernel 4.5-rc3+ or -rc5(?) after Dan sent me the > instructions to compile it, but I encountered completely different > issues with it and reinstalled Fedora a few days ago. I will recompile > again if necessary, especially if it will help your team with > troubleshooting these issues. > It's still possible to trigger this bug with ATS heartbeat disabled once ESX thinks SCSI I/O latency too high, and begins to generate repeated ABORT_TASK and eventual LUN_RESET events to a backend device across multiple ESX VMFS host exports. It's unclear how much latency disabling ATS heartbeat support reduces within ESX's internal stack, but as long as you're still observing constant ABORT_TASKs events regardless of ATS heartbeat usage it's possible to trigger the target bug. -- 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
