On 28/02/2018 04:14, Jason Yan wrote:
On 2018/2/27 23:00, Jack Wang wrote:
2018-02-27 12:50 GMT+01:00 John Garry <john.ga...@huawei.com>:
On 27/02/2018 06:59, Jason Yan wrote:
When ata device doing EH, some commands still attached with tasks
passed to libata when abort failed or recover failed, so libata did not
handle these commands. After these commands done, sas task is freed,
ata qc is not freed. This will cause ata qc leak and trigger a warning
It's seems like a bug that we're just killing the ATA command in libsas
error handling and not deferring them to ATA EH also.
And this WARN, below, in ata_eh_finish() is a longterm issue I see (but
maybe because of other issue also).
As mentioned to Jason privately, I wonder why Dan's patch excluded the
Author: Dan Williams <dan.j.willi...@intel.com>
Date: Tue Nov 29 12:08:50 2011 -0800
[SCSI] libsas: let libata handle command timeouts
libsas-eh if it successfully aborts an ata command will hide the
condition (AC_ERR_TIMEOUT) from libata. The command likely
with the all-zero task->task_status it started with. Instead,
a TMF_RESP_FUNC_COMPLETE as the end of the sas_task but keep the
around for libata-eh to handle.
Tested-by: Andrzej Jakowski <andrzej.jakow...@intel.com>
Signed-off-by: Dan Williams <dan.j.willi...@intel.com>
Signed-off-by: James Bottomley <jbottom...@parallels.com>
WARNING: CPU: 0 PID: 28512 at drivers/ata/libata-eh.c:4037
CPU: 0 PID: 28512 Comm: kworker/u32:2 Tainted: G W OE 4.14.0#1
Hi John, hi Jason,
We've seen this warning once on pm80xx with sata SSD in production (on
3.12 kernel), but failed to see the root cause.
In my case, it's a chain sequence, one SSD failed, lead to error
handle & IO stuck.
Do you have reproducer?
I have found this warning several times when our test team running a
very large test suite. Sorry to say that I do not have a simple
Typically we would see this when commands timeout after we unplug a SATA
disk with IO in flight, right?
Your change looks good to me, but would be good to hear from Dan & James.