linux-stable.git/drivers/s390, branch v2.6.30

[SCSI] zfcp: Fix oops when port disappears

2009-04-27T15:07:37+00:00

The zfcp_port might have been removed, while the FC fast_io_fail timer
is still running and could trigger the terminate_rport_io callback.
Set the pointer to the zfcp_port to NULL and check accordingly
before using it.

Reviewed-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: Reference counting for cfdc requests

2009-04-27T15:07:36+00:00

Before dropping the reference count with zfcp_adapter_put, increase it
with zfcp_adapter_get when issuing cfdc requests.

Reviewed-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: Fix port reference counting

2009-04-27T15:07:35+00:00

If this problem appears zfcp ports cannot be de-queued since it is
checked for a zero refcount. The port reference counting is wrong for
existing zfcp ports when e.g. an adapter gets on-line again. During
port scanning the reference counting for existing ports should not be
changed.

Signed-off-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: revert previous patch for sbal counting

2009-04-27T15:07:34+00:00

The current sbal counting can be wrong if a fsf request is
waiting for free sbals and at the same time qdio request queue
is shutdown and re-opened. Revering a previous patch fixes this
issue.

Signed-off-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: Fix abort handler for completions in progress

2009-04-27T15:07:33+00:00

When the abort handler cannot find a pending FSF request, the request
completion could just be running. This means we cannot return SUCCESS,
since this would lead to call to scsi_done after exiting the SCSI
error handler which is not allowed.

Reviewed-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: no port recovery after ADISC request timeout

2009-04-27T15:07:32+00:00

A remote port remains in error state even if we receive a RSCN
stating that the connection is re-established. The port recovery
is not started due to a flag which is not reset.
The solution is to clear the flag in question before we trigger a ERP.

Signed-off-by: Swen Schillig 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: Let actcli handle control file errors

2009-04-27T15:07:31+00:00

Error codes specific to the control file requests are evaluated by the
actcli tool, so don't report -ENXIO for those. Generic problems are
still checked for outside the command specific handler.

Reviewed-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: remove unit will fail if add unit is not finished

2009-04-27T15:07:31+00:00

On some hardware it can take some time to add a unit. If
some remove this unit during this process the remove will
fail.

Signed-off-by: Martin Petermann 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: no port recovery after storage side error inject

2009-04-27T15:07:29+00:00

The remote port remains in error state even if the connection
is re-established. A wrong precondition check was performed on
the port status leading to a cancellation of the port reopen.
Remove the pre-req check because it's not required and better
handled within the ERP.

Signed-off-by: Swen Schillig 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley

[SCSI] zfcp: avoid false ERP complete due to sema race

2009-04-27T15:07:28+00:00

The ERP thread is performing a task before it is executing the
corresponding down on the semaphore. The response handler of the
just started exchange config should wait for the completion by
performing a down on this semaphore. Since this semaphore is still
positive from the ERP enqueue the handler won't wait and therefore
the exchange config will always fail leaving the adapter in error.
The problem can be solved by performing the down on the semaphore
before starting an ERP task. This is the logically correct order.
Only walk the ERP loop if there is a task to perform.

Signed-off-by: Swen Schillig 
Signed-off-by: Christof Schmitt 
Signed-off-by: James Bottomley