zfcp: updates, fixing a variety of oddities
Subsystems (3)
cover zfcp: updates, fixing a variety of oddities
Signature · 40 lines
patch 1/6: Remove unnecessary eh_bus_reset_handler callsback
The callback function used by zfcp always returns success,
which is an indication for the SCSI midlayer to stop error
handling. Remove the bus_reset callback, since the same
function will be called via the host_reset callback.
patch 2/6: Use also port and adapter to identify unit in messages
Add the appropriate messages.
patch 3/6: Specify waiting times in ERP in seconds
It is not necessary to use jiffies or milliseconds to specify
waiting times that last a couple of seconds.
patch 4/6: Remove SCSI devices when removing adapter
The common I/O layer can call remove a handler to inform zfcp
that a device disappeared. The handler zfcp_ccw_remove then
removes all unit, port and the adapter data structures. Removing
the units requires that the SCSI devices are removed first.
patch 5/6: Fix deadlock when adding invalid LUN
When adding an invalid LUN, there is a deadlock between the add
via scsi_scan_target and the slave_destroy handler: The handler
waits for the scan to complete, but for an invalid unit,
scsi_scan_target directly calls the slave_destroy handler.
Fix the deadlock by removing the wait in the slave_destroy
handler, it was not necessary anyway.
patch 6/6: Reduce flood on HBA trace
Remove tracing for request with a "qualifier" field set in the
response. Â The protocol status qualifier now contains measurement
data for "good" commands, so this check would trace every response
by default.
The fix is to simply remove the "qual" tracing: The responses with an
interesting status are also traced as "ferr" or "perr" and all
responses can be traced as "norm" with a higher trace level.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlPATCH 1/6 zfcp: Remove unnecessary eh_bus_reset_handler callback
From: Christof Schmitt <[email protected]>
The callback function used by zfcp always returns success, which is an indication for the SCSI midlayer to stop error handling. Remove the bus_reset callback, since the same function will be called via the host_reset callback.
Signed-off-by Christof Schmitt <[email protected]>
Signed-off-by Swen Schillig <[email protected]>
---
drivers/s390/scsi/zfcp_scsi.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/s390/scsi/zfcp_scsi.c +2 -3
@@ -51,7 +51,6 @@ struct zfcp_data zfcp_data = { .queuecommand = zfcp_scsi_queuecommand, .eh_abort_handler = zfcp_scsi_eh_abort_handler, .eh_device_reset_handler = zfcp_scsi_eh_device_reset_handler, - .eh_bus_reset_handler = zfcp_scsi_eh_host_reset_handler, .eh_host_reset_handler = zfcp_scsi_eh_host_reset_handler, .can_queue = 4096, .this_id = -1,
@@ -542,7 +541,7 @@ zfcp_task_management_function(struct zfc }/** -* zfcp_scsi_eh_host_reset_handler - handler for host and bus reset +* zfcp_scsi_eh_host_reset_handler - handler for host reset */ static int zfcp_scsi_eh_host_reset_handler (struct scsi_cmnd *scpnt) {
@@ -552,7 +551,7 @@ static int zfcp_scsi_eh_host_reset_handl unit = (struct zfcp_unit *) scpnt->device->hostdata; adapter = unit->port->adapter; -ZFCP_LOG_NORMAL ("host/bus reset because of problems with " +ZFCP_LOG_NORMAL ("host reset because of problems with " "unit 0x%016Lx\n" , unit->fcp_lun);zfcp_erp_adapter_reopen (adapter,0 );
PATCH 2/6 zfcp: Use also port and adapter to identify unit in messages.
In reply to [email protected]From: Christof Schmitt <[email protected]>
Signed-off-by Christof Schmitt <[email protected]>
Signed-off-by Swen Schillig <[email protected]>
---
drivers/s390/scsi/zfcp_scsi.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/s390/scsi/zfcp_scsi.c +6 -2
@@ -458,7 +458,9 @@ zfcp_scsi_eh_device_reset_handler(struct retval =SUCCESS ; goto out; } -ZFCP_LOG_NORMAL ("resetting unit 0x%016Lx\n" , unit->fcp_lun); +ZFCP_LOG_NORMAL ("resetting unit 0x%016Lx on port 0x%016Lx, adapter %s\n" , + unit->fcp_lun, unit->port->wwpn, +zfcp_get_busid_by_adapter (unit->port->adapter));/* * If we do not know whether the unit supports 'logical unit reset'
@@ -552,7 +554,9 @@ static int zfcp_scsi_eh_host_reset_handl adapter = unit->port->adapter;ZFCP_LOG_NORMAL ("host reset because of problems with " -"unit 0x%016Lx\n" , unit->fcp_lun); +"unit 0x%016Lx on port 0x%016Lx, adapter %s\n" , + unit->fcp_lun, unit->port->wwpn, +zfcp_get_busid_by_adapter (unit->port->adapter));zfcp_erp_adapter_reopen (adapter,0 );zfcp_erp_wait (adapter);
PATCH 3/6 zfcp: Specify waiting times in ERP in seconds
In reply to [email protected]From: Christof Schmitt <[email protected]>
It is not necessary to use jiffies or milliseconds to specify waiting times that last a couple of seconds.
Signed-off-by Christof Schmitt <[email protected]>
Signed-off-by Martin Schwidefsky <[email protected]>
Signed-off-by Swen Schillig <[email protected]>
---
drivers/s390/scsi/zfcp_def.h | 4 ++-- drivers/s390/scsi/zfcp_erp.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-)
drivers/s390/scsi/zfcp_def.h +2 -2
@@ -117,7 +117,7 @@ zfcp_address_to_sg(void *address, struct#define ZFCP_SBAL_TIMEOUT (5*HZ) -#define ZFCP_TYPE2_RECOVERY_TIME (8*HZ) +#define ZFCP_TYPE2_RECOVERY_TIME 8/* seconds */ /* queue polling (values in microseconds) */ #define ZFCP_MAX_INPUT_THRESHOLD 5000/* FIXME: tune */
@@ -138,7 +138,7 @@ zfcp_address_to_sg(void *address, struct#define ZFCP_STATUS_READS_RECOM FSF_STATUS_READS_RECOM/* Do 1st retry in 1 second, then double the timeout for each following retry */ -#define ZFCP_EXCHANGE_CONFIG_DATA_FIRST_SLEEP 100 +#define ZFCP_EXCHANGE_CONFIG_DATA_FIRST_SLEEP 1#define ZFCP_EXCHANGE_CONFIG_DATA_RETRIES 7/* timeout value for "default timer" for fsf requests */
drivers/s390/scsi/zfcp_erp.c +4 -4
@@ -131,7 +131,7 @@ static void zfcp_close_qdio(struct zfcp_debug_text_event (adapter->erp_dbf,3 ,"qdio_down2a" );while (qdio_shutdown (adapter->ccw_device,QDIO_FLAG_CLEANUP_USING_CLEAR ) == -EINPROGRESS ) -msleep (1000 ); +ssleep (1 );debug_text_event (adapter->erp_dbf,3 ,"qdio_down2b" );/* cleanup used outbound sbals */
@@ -1900,7 +1900,7 @@ zfcp_erp_adapter_strategy(struct zfcp_erZFCP_LOG_INFO ("Waiting to allow the adapter %s " "to recover itself\n" ,zfcp_get_busid_by_adapter (adapter)); -msleep (jiffies_to_msecs (ZFCP_TYPE2_RECOVERY_TIME )); +ssleep (ZFCP_TYPE2_RECOVERY_TIME ); }return retval;
@@ -2080,7 +2080,7 @@ zfcp_erp_adapter_strategy_open_qdio(strudebug_text_event (adapter->erp_dbf,3 ,"qdio_down1a" );while (qdio_shutdown (adapter->ccw_device,QDIO_FLAG_CLEANUP_USING_CLEAR ) == -EINPROGRESS ) -msleep (1000 ); +ssleep (1 );debug_text_event (adapter->erp_dbf,3 ,"qdio_down1b" ); failed_qdio_establish:
@@ -2165,7 +2165,7 @@ zfcp_erp_adapter_strategy_open_fsf_xconfZFCP_LOG_DEBUG ("host connection still initialising... " "waiting and retrying...\n" );/* sleep a little bit before retry */ -msleep (jiffies_to_msecs (sleep)); +ssleep (sleep); sleep *=2 ; }
PATCH 4/6 zfcp: Remove SCSI devices when removing complete adapter
In reply to [email protected]From: Christof Schmitt <[email protected]>
The common I/O layer can call remove a handler to inform zfcp that a device disappeared. The handler zfcp_ccw_remove then removes all unit, port and the adapter data structures. Removing the units requires that the SCSI devices are removed first.
Signed-off-by Christof Schmitt <[email protected]>
Signed-off-by Swen Schillig <[email protected]>
---
drivers/s390/scsi/zfcp_ccw.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/s390/scsi/zfcp_ccw.c +3 -0
@@ -120,6 +120,9 @@ zfcp_ccw_remove(struct ccw_device *ccw_dlist_for_each_entry_safe (port, p, &adapter->port_remove_lh, list) {list_for_each_entry_safe (unit, u, &port->unit_remove_lh, list) { +if (atomic_test_mask (ZFCP_STATUS_UNIT_REGISTERED , + &unit->status)) +scsi_remove_device (unit->device);zfcp_unit_dequeue (unit); }zfcp_port_dequeue (port);
PATCH 5/6 zfcp: Fix deadlock when adding invalid LUN
In reply to [email protected]From: Christof Schmitt <[email protected]>
When adding an invalid LUN, there is a deadlock between the add via scsi_scan_target and the slave_destroy handler: The handler waits for the scan to complete, but for an invalid unit, scsi_scan_target directly calls the slave_destroy handler.
Fix the deadlock by removing the wait in the slave_destroy handler, it was not necessary anyway.
Signed-off-by Christof Schmitt <[email protected]>
Signed-off-by Martin Schwidefsky <[email protected]>
Signed-off-by Swen Schillig <[email protected]>
---
drivers/s390/scsi/zfcp_aux.c | 2 -- drivers/s390/scsi/zfcp_def.h | 4 ---- drivers/s390/scsi/zfcp_erp.c | 1 - drivers/s390/scsi/zfcp_scsi.c | 3 --- 4 files changed, 10 deletions(-)
drivers/s390/scsi/zfcp_aux.c +0 -2
@@ -844,8 +844,6 @@ zfcp_unit_enqueue(struct zfcp_port *port unit->sysfs_device.release = zfcp_sysfs_unit_release;dev_set_drvdata (&unit->sysfs_device, unit); -init_waitqueue_head (&unit->scsi_scan_wq); -/* mark unit unusable as long as sysfs registration is not complete */ atomic_set_mask (ZFCP_STATUS_COMMON_REMOVE , &unit->status);
drivers/s390/scsi/zfcp_def.h +0 -4
@@ -982,10 +982,6 @@ struct zfcp_unit {struct scsi_device *device;/* scsi device struct pointer */ struct zfcp_erp_action erp_action;/* pending error recovery */ atomic_t erp_counter; -wait_queue_head_t scsi_scan_wq;/* can be used to wait until -all scsi_scan_target -requests have been -completed. */ };/* FSF request */
drivers/s390/scsi/zfcp_erp.c +0 -1
@@ -1609,7 +1609,6 @@ static void zfcp_erp_scsi_scan(struct woscsi_scan_target (&rport->dev,0 , rport->scsi_target_id, unit->scsi_lun,0 );atomic_clear_mask (ZFCP_STATUS_UNIT_SCSI_WORK_PENDING , &unit->status); -wake_up (&unit->scsi_scan_wq);zfcp_unit_put (unit);kfree (p); }
drivers/s390/scsi/zfcp_scsi.c +0 -3
@@ -180,9 +180,6 @@ static void zfcp_scsi_slave_destroy(struif (unit) {zfcp_erp_wait (unit->port->adapter); -wait_event (unit->scsi_scan_wq, -atomic_test_mask (ZFCP_STATUS_UNIT_SCSI_WORK_PENDING , - &unit->status) ==0 );atomic_clear_mask (ZFCP_STATUS_UNIT_REGISTERED , &unit->status); sdpnt->hostdata =NULL ; unit->device =NULL ;
PATCH 6/6 zfcp: Reduce flood on hba trace
In reply to [email protected]From: Christof Schmitt <[email protected]>
Remove tracing for request with a "qualifier" field set in the response. The protocol status qualifier now contains measurement data for "good" commands, so this check would trace every response by default.
The fix is to simply remove the "qual" tracing: The responses with an interesting status are also traced as "ferr" or "perr" and all responses can be traced as "norm" with a higher trace level.
Signed-off-by Christof Schmitt <[email protected]>
Signed-off-by Swen Schillig <[email protected]>
---
drivers/s390/scsi/zfcp_dbf.c | 6 ------ 1 file changed, 6 deletions(-)
drivers/s390/scsi/zfcp_dbf.c +0 -6
@@ -161,12 +161,6 @@ void zfcp_hba_dbf_event_fsf_response(str (fsf_req->fsf_command == FSF_QTCB_OPEN_LUN)) { strncpy(rec->tag2, "open", ZFCP_DBF_TAG_SIZE); level = 4; - } else if ((prot_status_qual->doubleword[0] != 0) || - (prot_status_qual->doubleword[1] != 0) || - (fsf_status_qual->doubleword[0] != 0) || - (fsf_status_qual->doubleword[1] != 0)) { -strncpy (rec->tag2,"qual" ,ZFCP_DBF_TAG_SIZE ); - level =3 ; } else {strncpy (rec->tag2,"norm" ,ZFCP_DBF_TAG_SIZE ); level =6 ;