Andrew Vasquez wrote:
From: Seokmann Ju <seokmann.ju@xxxxxxxxxx>
Signed-off-by: Seokmann Ju <seokmann.ju@xxxxxxxxxx>
Signed-off-by: Andrew Vasquez <andrew.vasquez@xxxxxxxxxx>
---
On Fri, 11 Jul 2008, Mike Christie wrote:
> Andrew Vasquez wrote:
>> +
>> +static void
>> +qla2x00_terminate_rport_io(struct fc_rport *rport)
>> +{
>> + fc_port_t *fcport = *(fc_port_t **)rport->dd_data;
>> +
>> + qla2x00_abort_fcport_cmds(fcport);
>> + scsi_target_unblock(&rport->dev);
>
> I sent a patch so the unblock is always done by the fc class.
> http://marc.info/?l=linux-scsi&m=121263015008613&w=2
>
> Could we do that instead so qlogic and emulex and all other drivers behave
> the same?
Sure. Here's a recut of the patch without the explicit
scsi_target_unblock().
Thanks, I think maybe your first patch should go in with this patchset
now. Later when my patch goes in I will cleanup the unblock for you.
Well, actually I guess it is buggy either way :) I think you guys need
it right now for when the terminate callback is called when we remove
the port. But if the terminate callback is called for just when the fast
io fail tmo fires, we would unblock the queue and then IO in there will
just bounce around because when it hits the queuecommand the rport
chkready function will just queue it back up. My patches allow us to
fail the IO instead of having it bounce around.
JamesB and JamesS, what do you guys think of my patches? I can just do
this one
http://marc.info/?l=linux-scsi&m=121263015008613&w=2
(but not use the DID_TRANSPORT_ values)
so that we do not hit the problem above. I will also add some
scsi_target_unblock calls when the terminate call back is called for
rport removal so the drivers do not have to handle in those cases too.
--
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
