[patch 13/13] zfcp: fix double dbf id usage

[Christof Schmitt <christof.schmitt@xxxxxxxxxx>]

From: Swen Schillig <swen@xxxxxxxxxxxx>

Trace ids 107 and 3 are used twice, fix this to have unique ids for
the erp triggers.

Signed-off-by: Swen Schillig <swen@xxxxxxxxxxxx>
Signed-off-by: Christof Schmitt <christof.schmitt@xxxxxxxxxx>
---
 drivers/s390/scsi/zfcp_dbf.c |    2 +-
 drivers/s390/scsi/zfcp_erp.c |    2 +-
 drivers/s390/scsi/zfcp_fsf.c |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/s390/scsi/zfcp_dbf.c	2008-09-30 13:51:51.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_dbf.c	2008-09-30 13:52:47.000000000 +0200
@@ -572,7 +572,7 @@ static const char *zfcp_rec_dbf_ids[] = 
 	[81]	= "shared read-write unit access unsupported",
 	[82]	= "incoming rscn",
 	[83]	= "incoming wwpn",
-	[84]	= "",
+	[84]	= "wka port handle not valid close port",
 	[85]	= "online",
 	[86]	= "offline",
 	[87]	= "ccw device gone",
--- a/drivers/s390/scsi/zfcp_fsf.c	2008-09-30 13:52:06.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_fsf.c	2008-09-30 13:52:47.000000000 +0200
@@ -1641,7 +1641,7 @@ static void zfcp_fsf_close_wka_port_hand
 
 	if (req->qtcb->header.fsf_status == FSF_PORT_HANDLE_NOT_VALID) {
 		req->status |= ZFCP_STATUS_FSFREQ_ERROR;
-		zfcp_erp_adapter_reopen(wka_port->adapter, 0, 107, req);
+		zfcp_erp_adapter_reopen(wka_port->adapter, 0, 84, req);
 	}
 
 	wka_port->status = ZFCP_WKA_PORT_OFFLINE;
--- a/drivers/s390/scsi/zfcp_erp.c	2008-09-30 13:52:38.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_erp.c	2008-09-30 13:52:47.000000000 +0200
@@ -1443,7 +1443,7 @@ void zfcp_erp_thread_kill(struct zfcp_ad
 {
 	atomic_set_mask(ZFCP_STATUS_ADAPTER_ERP_THREAD_KILL, &adapter->status);
 	up(&adapter->erp_ready_sem);
-	zfcp_rec_dbf_event_thread_lock(2, adapter);
+	zfcp_rec_dbf_event_thread_lock(3, adapter);
 
 	wait_event(adapter->erp_thread_wqh,
 		   !(atomic_read(&adapter->status) &

-- 
--
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