On Fri, 2014-06-27 at 13:04 +0200, Hannes Reinecke wrote:
> On 06/27/2014 12:47 PM, Steffen Maier wrote:
> > On 06/27/2014 08:27 AM, Hannes Reinecke wrote:
> >> Issuing a host reset should not rely on any commands.
> >> So use Scsi_Host as argument for eh_host_reset_handler.
> >>
> >> Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
> >> ---
> >
> >> drivers/s390/scsi/zfcp_scsi.c | 3 +-
> >
> >> 69 files changed, 289 insertions(+), 379 deletions(-)
> >
> >> diff --git a/drivers/s390/scsi/zfcp_scsi.c
> >> b/drivers/s390/scsi/zfcp_scsi.c
> >> index dc42c93..fe50f69 100644
> >> --- a/drivers/s390/scsi/zfcp_scsi.c
> >> +++ b/drivers/s390/scsi/zfcp_scsi.c
> >> @@ -281,13 +281,14 @@ static int
> >> zfcp_scsi_eh_target_reset_handler(struct scsi_cmnd *scpnt)
> >> return zfcp_task_mgmt_function(scpnt, FCP_TMF_TGT_RESET);
> >> }
> >>
> >> -static int zfcp_scsi_eh_host_reset_handler(struct scsi_cmnd *scpnt)
> >> +static int zfcp_scsi_eh_host_reset_handler(struct Scsi_Host *host)
> >> {
> >> struct zfcp_scsi_dev *zfcp_sdev = sdev_to_zfcp(scpnt->device);
> >
> > Scpnt argument no longer exists, so this line must likely go away to
> > compile.
> >
> >> struct zfcp_adapter *adapter = zfcp_sdev->port->adapter;
> >
> > This needs the assignment from the added line below since zfcp_sdev
> > no longer exists.
> > Alternatively, drop the assignment here, only have the auto variable
> > definition, and do the assignment below with the added line.
> >
> >> struct fc_rport *rport = zfcp_sdev->port->rport;
> >> int ret;
> >>
> >> + adapter = (struct zfcp_adapter *)host->hostdata[0];
> >> zfcp_erp_adapter_reopen(adapter, 0, "schrh_1");
> >> zfcp_erp_wait(adapter);
> >> ret = fc_block_scsi_eh(rport);
> >
> > A question just for my understanding: Calling fc_block_scsi_eh at
> > the end *after* our adapter recovery is OK to wait for rports to
> > become unblocked (or fast_io_failed)?
> > I would guess so.
> >
> Hehe. That's actually a question for _you_ :-)
git says:
commit af4de36d911ab907b92c5f3f81ceff8474ed7485
Author: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
Date: Tue Nov 24 16:54:16 2009 +0100
[SCSI] zfcp: Block scsi_eh thread for rport state BLOCKED
In case the SCSI error recovery starts because of a SCSI command
timeout, but then something else triggers the rport to be deleted,
the SCSI error recovery will run to the end and set the SCSI device
offline. To prevent this, call the FC transport function
fc_block_scsi_eh which waits until the rport leaves the BLOCKED
state. This guarantees that communication is possible if the rport
is ONLINE, or the SCSI devices will be removed if the rport state
switches to NOT_PRESENT.
Not sure if this reasoning is (still) valid.
Isn't command timeouts the only reason for scsi eh to kick in?
Martin
--
Linux on System z Development
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
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
