Mike Christie wrote:
Michael Reed wrote:
michaelc@xxxxxxxxxxx wrote:
From: Mike Christie <michaelc@xxxxxxxxxxx>
Convert mptfc to use fc queueing helper.
I've been trying to exercise the fusion FC change.
I can't seem to force the code into returning either
TARGET_BUSY or DID_NO_CONNECT. Any suggestions on
Did you mean DID_IMM_RETRY in the original code?
how I might get a command down to the driver while
the rport is blocked or in DEVLOSS_PENDING?
I've been running 32 outstanding commands to 16 targets,
disabling/enabling the various FC switch ports, AND
I disabled the usage of the scsi_host_lock in
fc_remote_port_delete() and I unlock/relock it in the
mptfc_qmnd() function.
For FC it is a small window where the rport is being blocked but the
scsi_device is not yet in the blocked state. Instead of lots of targets
you want lots of devices on just one target.
To test it with just one device you can just add a sleep in
fc_remote_port_delete after the port_state and flags are set and the
host lock is dropped and before the call to scsi_target_block.
rport->port_state = FC_PORTSTATE_BLOCKED;
rport->flags |= FC_RPORT_DEVLOSS_PENDING;
spin_unlock_irqrestore(shost->host_lock, flags);
if (rport->roles & FC_PORT_ROLE_FCP_INITIATOR &&
shost->active_mode & MODE_TARGET)
fc_tgt_it_nexus_destroy(shost, (unsigned long)rport);
ssleep(1);
scsi_target_block(&rport->dev);
I think we could actually avoid the transition checks if we just held
the host lock around the code we set the port state and when we call
scsi_target_block. scsi_target_block would just need to be modified so
that it did not grab the host lock (the driver model code does not use a
mutex anymore).
On the scsi_target_unblock side we would grab the host lock and set the
rport state and unblock the devices at the same time. Again we would
need to not take the host lock when looping over the devices and we
could just plug the queue instead of running the request_fn (because
performance is not an issue in this code path instead of using
blk_start_queue we could call somehing that cleared the stop flag and
always plugged the queue).
--
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
