--- James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> While abusing my sas topology (to try to get it to give me errors) I
> came across this one with STP tasks:
>
> When the aic94xx loses a task in sas_execute_tasks(), the timeout fires
> and wakes the waiter (this leaves the task set pending and aborted). In
> response, sas_execute_task() tries to call lldd_abort_task()
> (asd_abort_task()) on it. Here we panic failing the BUG_ON(!list_empty)
> check in aic94xx_hwi.h:asd_ascb_free().
>
> What happens is that the abort comes back with TF_TMF_NO_CTX + 0xFF00
> from the sequencer, which asd_abort_task() treats as success and then
> panics because the original task is still active.
The sequencer response is correct but incomplete. The interpretation
is a bad compromize between SSP and STP.
TF_TMF_NO_CTX should be interpreted as TMF_RESP_FUNC_ESUPP to get
"best of both worlds", and then upper layers would do the proper
thing depending on the protocol.
Of course your version of my code and my version of my code differ
somewhat.
The fix in the sequencer is messy as is the fix in software.
Luben
>
> Either the abort function or the sequencer code is clearly wrong, but
> not having access to the sequencer to look, I can't tell. What should
> this return mean from the sequencer? My suspicion is that it means the
> STP task abort isn't actually formulated properly.
>
> James
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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 linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
