Hi Bryant & Co,
Apologies for the delayed follow up.
Comments below.
On Mon, 2017-04-10 at 13:52 -0500, Bryant G. Ly wrote:
> The driver is sending a response to the aborted task response
> along with LIO sending the tmr response.
> ibmvscsis_tgt does not send the response to the client until
>
On 04/10/2017 11:52 AM, Bryant G. Ly wrote:
> The driver is sending a response to the aborted task response
> along with LIO sending the tmr response.
I think this could be better worded. Something like the driver is sending a
response to
the actual ***scsi op*** that was aborted by an abort task
"Bryant G. Ly" writes:
> The driver is sending a response to the aborted task response along
> with LIO sending the tmr response. ibmvscsis_tgt does not send the
> response to the client until release_cmd time. The reason for this was
> because if we did it at queue_status time, then the client
The driver is sending a response to the aborted task response
along with LIO sending the tmr response.
ibmvscsis_tgt does not send the response to the client until
release_cmd time. The reason for this was because if we did it
at queue_status time, then the client would be free to reuse the
tag for
On Fri, 2017-04-07 at 16:14 -0500, Michael Cyr wrote:
> That then caused this issue, because release_cmd is always called, even
> if queue_status is not. Perhaps it would be cleaner to set some sort of
> status valid flag during queue_status instead of setting a flag in
> aborted_task?
Hello M
On 4/7/17 12:01 PM, Bryant G. Ly wrote:
On 4/7/17 11:36 AM, Bart Van Assche wrote:
On Fri, 2017-04-07 at 11:12 -0500, Bryant G. Ly wrote:
So from this stack trace it looks like the ibmvscsis driver is
sending an
extra response through send_messages even though an abort was issued.
IBMi, repo
On 4/7/17 11:36 AM, Bart Van Assche wrote:
On Fri, 2017-04-07 at 11:12 -0500, Bryant G. Ly wrote:
So from this stack trace it looks like the ibmvscsis driver is sending an
extra response through send_messages even though an abort was issued.
IBMi, reported this issue internally when they were
On Fri, 2017-04-07 at 11:12 -0500, Bryant G. Ly wrote:
> So from this stack trace it looks like the ibmvscsis driver is sending an
> extra response through send_messages even though an abort was issued.
> IBMi, reported this issue internally when they were testing the driver,
> because their clie
On 04/07/2017 08:49 AM, Bryant G. Ly wrote:
> The driver is sending a response to the aborted task response
That occurrence of "response" looks extraneous?
> along with LIO sending the tmr response. SCSI spec says
> that the initiator
On 4/7/17 10:49 AM, Bryant G. Ly wrote:
The driver is sending a response to the aborted task response
along with LIO sending the tmr response. SCSI spec says
that the initiator that sends the abort task TM NEVER gets a
response to the aborted op and with the current code it will
send a response
The driver is sending a response to the aborted task response
along with LIO sending the tmr response. SCSI spec says
that the initiator that sends the abort task TM NEVER gets a
response to the aborted op and with the current code it will
send a response. Thus this fix will remove that response if
11 matches
Mail list logo