> -----Original Message-----
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Andrew Brooks
> Sent: Tuesday, 16 December, 2014 4:23 AM
...
>
> On 8 December 2014 at 07:02, James Bottomley
> <james.bottom...@hansenpartnership.com> wrote:
> >
> > The error message likely means that the tape device had more than one
> > command outstanding at once (i.e. one command was sent while the current
> > command was still pending). It could also mean that a tag got re-used
> > (same tag issued while command with that tag was outstanding) but for a
> > tape I think the former is more likely. Is the queue depth set to one
> > for the device?
> >
...
>
> st0: Sense Key : Aborted Command [current]
> st0: Add. Sense: Tagged overlapped commands (task tag 0)
That error could be due to:
1. send command with tag 0
2. timeout command with tag 0
3. abort command with tag 0, doesn't get through
4. send new command with tag 0
What are the serial log messages preceding those messages?
For example, if you see this print from mv_sas.c mvs_abort_task():
if (rc == 0) {
mv_printk("No such tag in %s\n", __func__);
rc = TMF_RESP_FUNC_FAILED;
return rc;
}
and this from libsas.c:
case TMF_RESP_FUNC_FAILED:
SAS_DPRINTK("%s: task 0x%p failed to abort\n",
__func__, task);
return TASK_ABORT_FAILED;
}
then it didn't send the ABORT TASK at all. If it really needed
to, that could lead to an overlap in tag 0.
BTW, in SCSI architecture, ABORT TASK is supposed to return
a service response of FUNCTION COMPLETE rather than an error
if the tag is not present (e.g., because the command has
completed by the time the ABORT TASK was received), so the
mvs_abort_task() handling there is questionable.
---
Rob Elliott HP Server Storage
