we discovered this when futzing w/ the queue depth parameter for ata
disks behind the pm8006 controller. setting depth == 1 should disable
ncq, but the sysfs part silently fails and we continue sending the
fpdma command variants. no one else probably cares about the disabling
ncq path, but we do like to test.
anyway, adding both the ide and scsi lists because i'm not quite sure
there's a separate libsas list and a single commit seems better for
this.
\p
On Tue, 2016-12-20 at 10:15 -0800, Peter Chang wrote:
we discovered this when futzing w/ the queue depth parameter for ata
disks behind the pm8006 controller. setting depth == 1 should disable
ncq, but the sysfs part silently fails and we continue sending the
fpdma command variants. no one else probably cares about the
disabling ncq path, but we do like to test.
I'd actually disagree with this assertion; it's why tagging (what you
mean by ncq) and queue depth are separate. Queue depth represents the
number of outstanding commands we sent on the wire; however, it often
excludes things like sense probes and error handling commands, so
tagged depth==1 is a different operating environment from untagged.
Some transports actually have no untagged variant nowadays, so it's
physically impossible to disable tagging.
James
anyway, adding both the ide and scsi lists because i'm not quite sure
there's a separate libsas list and a single commit seems better for
this.
On Tue, Dec 20, 2016 at 10:30:34AM -0800, James Bottomley wrote:
I'd actually disagree with this assertion; it's why tagging (what you
mean by ncq) and queue depth are separate. Queue depth represents the
number of outstanding commands we sent on the wire; however, it often
excludes things like sense probes and error handling commands, so
tagged depth==1 is a different operating environment from untagged.
Some transports actually have no untagged variant nowadays, so it's
physically impossible to disable tagging.
Yes. We have the queue_type sysfs file that also used to be writeable
and allow changing the queue type, but it's never been used for
anything.
For debugging you can clear the tagged_supported flag in the driver,
but there should be no reason for doing that during normal operation
for a SAS HBA driver.