linux-toradex.git/drivers/s390, branch v2.6.31.10

S390: dasd: support DIAG access for read-only devices

2010-01-06T22:26:42+00:00

commit 22825ab7693fd29769518a0d25ba43c01a50092a upstream.

When a DASD device is used with the DIAG discipline, the DIAG
initialization will indicate success or error with a respective
return code. So far we have interpreted a return code of 4 as error,
but it actually means that the initialization was successful, but
the device is read-only. To allow read-only devices to be used with
DIAG we need to accept a return code of 4 as success.

Re-initialization of the DIAG access is also part of the DIAG error
recovery. If we find that the access mode of a device has been
changed from writable to read-only while the device was in use,
we print an error message.

Signed-off-by: Stefan Weinhuber 
Signed-off-by: Martin Schwidefsky 
Cc: Stephen Powell 
Signed-off-by: Greg Kroah-Hartman

[S390] drivers/s390: put NULL test before dereference

2009-08-23T16:10:00+00:00

If the NULL test on block is needed, it should be before the dereference of
the base field.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@r@
expression E1,E2;
identifier fld;
statement S1,S2;
@@

E1 = E2->fld;
(
if (E1 == NULL) S1 else S2
|
*if (E2 == NULL) S1 else S2
)
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Martin Schwidefsky

[S390] cio: fix double free after failed device initialization

2009-08-23T16:10:00+00:00

If io_subchannel_initialize_dev fails it will release the only
reference to the ccw device therefore the caller should not
kfree this device since this is done in the release function.

Signed-off-by: Sebastian Ott 
Signed-off-by: Martin Schwidefsky

Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6

2009-08-04T22:38:10+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: (23 commits)
  [SCSI] sd: Avoid sending extended inquiry to legacy devices
  [SCSI] libsas: fix wide port hotplug issues
  [SCSI] libfc: fix a circular locking warning during sending RRQ
  [SCSI] qla4xxx: Remove hiwat code so scsi eh does not get escalated when we can make progress
  [SCSI] qla4xxx: Fix srb lookup in qla4xxx_eh_device_reset
  [SCSI] qla4xxx: Fix Driver Fault Recovery Completion
  [SCSI] qla4xxx: add timeout handler
  [SCSI] qla4xxx: Correct Extended Sense Data Errors
  [SCSI] libiscsi: disable bh in and abort handler.
  [SCSI] zfcp: Fix tracing of request id for abort requests
  [SCSI] zfcp: Fix wka port processing
  [SCSI] zfcp: avoid double notify in lowmem scenario
  [SCSI] zfcp: Add port only once to FC transport class
  [SCSI] zfcp: Recover from stalled outbound queue
  [SCSI] zfcp: Fix erp escalation procedure
  [SCSI] zfcp: Fix logic for physical port close
  [SCSI] zfcp: Use -EIO for SBAL allocation failures
  [SCSI] zfcp: Use unchained mode for small ct and els requests
  [SCSI] zfcp: Use correct flags for zfcp_erp_notify
  [SCSI] zfcp: Return -ENOMEM for allocation failures in zfcp_fsf
  ...

[SCSI] zfcp: Fix tracing of request id for abort requests

2009-07-30T13:49:59+00:00

The trace record for SCSI abort requests has a field for the request
id of the request to be aborted. Put the real request id instead of
zero.

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

[SCSI] zfcp: Fix wka port processing

2009-07-30T13:49:58+00:00

Under certain conditions it is possible that a WKA port ist not opened
within the expected timeframe of half a second. In this situation
the WKA port remains in the state OPENING preventing any succeding
request to open the port. This led to unrecoverable remote ports.
Fixing this by always setting an appropriate WKA port status before
leaving the function and removing the timeout value here since it's
not needed here because the general timeout processing would deal
with it if required.

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

[SCSI] zfcp: avoid double notify in lowmem scenario

2009-07-30T13:49:58+00:00

In a LOWMEM condition an ERP notification would have been sent twice
causing an unpredictable behaviour of the ERP.

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

[SCSI] zfcp: Add port only once to FC transport class

2009-07-30T13:49:58+00:00

When calling fc_remote_port_add make sure to not call it again before
fc_remote_port_delete has been called. In other words, ensure to
create a new fc_rport, then delete it, then create a new one again.

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

[SCSI] zfcp: Recover from stalled outbound queue

2009-07-30T13:49:57+00:00

Depending on interruptions on some storage systems, the complete
channel can stall which looks like an outbound queue stall to Linux.
When trying to acquire a free SBAL for a non-SCSI command, zfcp waits
for 5 seconds for a free slot to appear. This is the right place to
detect a queue stall: If the wait times out, we assume a stalled queue
and try to recover this.

The overall strategy should be to trigger the erp from specific
events, and not try an overall escalation from one failed port to a
full-blown queue recovery. If we manage to send a command, the status
codes for this command or a timeout will trigger the right follow-on
actions.

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

[SCSI] zfcp: Fix erp escalation procedure

2009-07-30T13:49:57+00:00

If an action fails, retry it until the erp count exceeds the
threshold. If there is something fundamentally wrong, the FSF layer
will trigger a more appropriate action depending on the FSF status
codes.

The followup for successful actions is a different followup than
retrying failed actions, so split the code two functions to make this
clear.

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