Home Home > GIT Browse
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJiri Kosina <jkosina@suse.cz>2016-11-04 23:07:35 +0100
committerJiri Kosina <jkosina@suse.cz>2016-11-04 23:07:35 +0100
commitb45f205133523585cb7b3d808806085ea3de95d6 (patch)
treedd766be4e16bacede89c005097820772b0eeea35
parentb5a2cd21f4d3873cff0c51663565a3dacefca81e (diff)
parent3ea2a9cbc8c8332ec91b969fbbcada0cf1a8d156 (diff)
Merge remote-tracking branch 'origin/users/jjolly/SLE11-SP4/for-next' into SLE11-SP4
-rw-r--r--patches.arch/s390-sles11sp4-15-01-01-move-ptff.patch128
-rw-r--r--patches.arch/s390-sles11sp4-15-01-02-lpar-offset.patch178
-rw-r--r--patches.arch/s390-sles11sp4-15-02-zfcp-fix-ELS-GS-request-response-length-for-hardware.patch142
-rw-r--r--patches.arch/s390-sles11sp4-15-03-zfcp-close-window-with-unblocked-rport-during-rport-.patch188
-rw-r--r--patches.arch/s390-sles11sp4-15-04-01-zfcp-retain-trace-level-for-SCSI-and-HBA-FSF-respons.patch260
-rw-r--r--patches.arch/s390-sles11sp4-15-04-02-zfcp-restore-Dont-use-0-to-indicate-invalid-LUN-in-r.patch168
-rw-r--r--patches.arch/s390-sles11sp4-15-04-03-zfcp-trace-on-request-for-open-and-close-of-WKA-port.patch249
-rw-r--r--patches.arch/s390-sles11sp4-15-04-04-zfcp-restore-tracing-of-handle-for-port-and-LUN-with.patch177
-rw-r--r--patches.arch/s390-sles11sp4-15-04-05-zfcp-fix-D_ID-field-with-actual-value-on-tracing-SAN.patch224
-rw-r--r--patches.arch/s390-sles11sp4-15-04-06-zfcp-fix-payload-trace-length-for-SAN-request-respon.patch209
-rw-r--r--patches.arch/s390-sles11sp4-15-04-07-zfcp-trace-full-payload-of-all-SAN-records-req-resp-.patch338
-rw-r--r--patches.arch/s390-sles11sp4-15-04-08-scsi-zfcp-spin_lock_irqsave-is-not-nestable.patch38
-rw-r--r--patches.arch/s390-sles11sp4-15-05-cio-fix-accidental-interrupt-enabling-during-re.patch139
-rw-r--r--series.conf14
14 files changed, 2452 insertions, 0 deletions
diff --git a/patches.arch/s390-sles11sp4-15-01-01-move-ptff.patch b/patches.arch/s390-sles11sp4-15-01-01-move-ptff.patch
new file mode 100644
index 0000000000..b6f3156098
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-01-01-move-ptff.patch
@@ -0,0 +1,128 @@
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Subject: s390/time: move PTFF definitions
+Patch-mainline: v4.8-rc1
+Git-commit: 9dc06ccf4699db81b88a6ff45a8acefd6c278327
+References: bnc#1003677, LTC#146920
+
+Description: kernel: tolerate LPAR clock offsets
+Symptom: The remote copy of a DASD in an extended-remote-copy setup
+ can get inconsistent due to misorder of I/O requests.
+Problem: If the activation profile of an LPAR specifies a logical-
+ partition time offset, the time stamps stored by the
+ get_sync_clock function includes this offset. With two
+ LPARs writing to a shared DASD but using different clock
+ offsets the I/O requests may be ordered incorrectly.
+Solution: Use the PTFF instruction to retrieve the TOD clock offset
+ and subtract it from the TOD clock value to get physical
+ timestamps.
+Reproduction: Write to a shared DASD volume on two LPARs with differing
+ logical-partition time offsets and use XRC to copy the
+ volume to a secondary volume. Compare the two volumes.
+
+Upstream-Description:
+
+ s390/time: move PTFF definitions
+
+ The PTFF instruction is not a function of ETR, rename and move the
+ PTFF definitions from etr.h to timex.h.
+
+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+
+
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ arch/s390/include/asm/etr.h | 32 --------------------------------
+ arch/s390/include/asm/timex.h | 33 +++++++++++++++++++++++++++++++++
+ 2 files changed, 33 insertions(+), 32 deletions(-)
+
+--- a/arch/s390/include/asm/etr.h
++++ b/arch/s390/include/asm/etr.h
+@@ -131,14 +131,6 @@ struct etr_irq_parm {
+ unsigned int _pad2 : 18;
+ } __attribute__ ((packed));
+
+-/* Query TOD offset result */
+-struct etr_ptff_qto {
+- unsigned long long physical_clock;
+- unsigned long long tod_offset;
+- unsigned long long logical_tod_offset;
+- unsigned long long tod_epoch_difference;
+-} __attribute__ ((packed));
+-
+ /* Inline assembly helper functions */
+ static inline int etr_setr(struct etr_eacr *ctrl)
+ {
+@@ -188,30 +180,6 @@ static inline int etr_steai(struct etr_a
+ #define ETR_STEAI_PORT_0 0x12
+ #define ETR_STEAI_PORT_1 0x13
+
+-static inline int etr_ptff(void *ptff_block, unsigned int func)
+-{
+- register unsigned int reg0 asm("0") = func;
+- register unsigned long reg1 asm("1") = (unsigned long) ptff_block;
+- int rc = -ENOSYS;
+-
+- asm volatile(
+- " .word 0x0104\n"
+- " ipm %0\n"
+- " srl %0,28\n"
+- : "=d" (rc), "=m" (ptff_block)
+- : "d" (reg0), "d" (reg1), "m" (ptff_block) : "cc");
+- return rc;
+-}
+-
+-/* Function codes for the ptff instruction. */
+-#define ETR_PTFF_QAF 0x00 /* query available functions */
+-#define ETR_PTFF_QTO 0x01 /* query tod offset */
+-#define ETR_PTFF_QSI 0x02 /* query steering information */
+-#define ETR_PTFF_ATO 0x40 /* adjust tod offset */
+-#define ETR_PTFF_STO 0x41 /* set tod offset */
+-#define ETR_PTFF_SFS 0x42 /* set fine steering rate */
+-#define ETR_PTFF_SGS 0x43 /* set gross steering rate */
+-
+ /* Functions needed by the machine check handler */
+ void etr_switch_to_local(void);
+ void etr_sync_check(void);
+--- a/arch/s390/include/asm/timex.h
++++ b/arch/s390/include/asm/timex.h
+@@ -53,6 +53,39 @@ static inline void store_clock_comparato
+
+ void clock_comparator_work(void);
+
++/* Function codes for the ptff instruction. */
++#define PTFF_QAF 0x00 /* query available functions */
++#define PTFF_QTO 0x01 /* query tod offset */
++#define PTFF_QSI 0x02 /* query steering information */
++#define PTFF_ATO 0x40 /* adjust tod offset */
++#define PTFF_STO 0x41 /* set tod offset */
++#define PTFF_SFS 0x42 /* set fine steering rate */
++#define PTFF_SGS 0x43 /* set gross steering rate */
++
++/* Query TOD offset result */
++struct ptff_qto {
++ unsigned long long physical_clock;
++ unsigned long long tod_offset;
++ unsigned long long logical_tod_offset;
++ unsigned long long tod_epoch_difference;
++} __packed;
++
++static inline int ptff(void *ptff_block, size_t len, unsigned int func)
++{
++ typedef struct { char _[len]; } addrtype;
++ register unsigned int reg0 asm("0") = func;
++ register unsigned long reg1 asm("1") = (unsigned long) ptff_block;
++ int rc;
++
++ asm volatile(
++ " .word 0x0104\n"
++ " ipm %0\n"
++ " srl %0,28\n"
++ : "=d" (rc), "+m" (*(addrtype *) ptff_block)
++ : "d" (reg0), "d" (reg1) : "cc");
++ return rc;
++}
++
+ static inline unsigned long long local_tick_disable(void)
+ {
+ unsigned long long old;
diff --git a/patches.arch/s390-sles11sp4-15-01-02-lpar-offset.patch b/patches.arch/s390-sles11sp4-15-01-02-lpar-offset.patch
new file mode 100644
index 0000000000..8df4a26a4f
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-01-02-lpar-offset.patch
@@ -0,0 +1,178 @@
+From: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Subject: s390/time: LPAR offset handling
+Patch-mainline: v4.8-rc1
+Git-commit: 4027789192d149678262ad606b2d7e2a61bed0f2
+References: bnc#1003677, LTC#146920
+
+Description: kernel: tolerate LPAR clock offsets
+Symptom: The remote copy of a DASD in an extended-remote-copy setup
+ can get inconsistent due to misorder of I/O requests.
+Problem: If the activation profile of an LPAR specifies a logical-
+ partition time offset, the time stamps stored by the
+ get_sync_clock function includes this offset. With two
+ LPARs writing to a shared DASD but using different clock
+ offsets the I/O requests may be ordered incorrectly.
+Solution: Use the PTFF instruction to retrieve the TOD clock offset
+ and subtract it from the TOD clock value to get physical
+ timestamps.
+Reproduction: Write to a shared DASD volume on two LPARs with differing
+ logical-partition time offsets and use XRC to copy the
+ volume to a secondary volume. Compare the two volumes.
+
+Upstream-Description:
+
+ s390/time: LPAR offset handling
+
+ It is possible to specify a user offset for the TOD clock, e.g. +2 hours.
+ The TOD clock will carry this offset even if the clock is synchronized
+ with STP. This makes the time stamps acquired with get_sync_clock()
+ useless as another LPAR migth use a different TOD offset.
+
+ Use the PTFF instrution to get the TOD epoch difference and subtract
+ it from the TOD clock value to get a physical timestamp. As the epoch
+ difference contains the sync check delta as well the LPAR offset value
+ to the physical clock needs to be refreshed after each clock
+ synchronization.
+
+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+
+
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ arch/s390/include/asm/timex.h | 13 +++++++++++++
+ arch/s390/kernel/early.c | 1 +
+ arch/s390/kernel/time.c | 41 +++++++++++++++++++++++++++++++++++------
+ 3 files changed, 49 insertions(+), 6 deletions(-)
+
+--- a/arch/s390/include/asm/timex.h
++++ b/arch/s390/include/asm/timex.h
+@@ -53,6 +53,11 @@ static inline void store_clock_comparato
+
+ void clock_comparator_work(void);
+
++void __init ptff_init(void);
++
++extern unsigned char ptff_function_mask[16];
++extern unsigned long lpar_offset;
++
+ /* Function codes for the ptff instruction. */
+ #define PTFF_QAF 0x00 /* query available functions */
+ #define PTFF_QTO 0x01 /* query tod offset */
+@@ -70,6 +75,14 @@ struct ptff_qto {
+ unsigned long long tod_epoch_difference;
+ } __packed;
+
++static inline int ptff_query(unsigned int nr)
++{
++ unsigned char *ptr;
++
++ ptr = ptff_function_mask + (nr >> 3);
++ return (*ptr & (0x80 >> (nr & 7))) != 0;
++}
++
+ static inline int ptff(void *ptff_block, size_t len, unsigned int func)
+ {
+ typedef struct { char _[len]; } addrtype;
+--- a/arch/s390/kernel/early.c
++++ b/arch/s390/kernel/early.c
+@@ -445,6 +445,7 @@ void __init startup_init(void)
+ ipl_save_parameters();
+ rescue_initrd();
+ clear_bss_section();
++ ptff_init();
+ init_kernel_storage_key();
+ lockdep_init();
+ lockdep_off();
+--- a/arch/s390/kernel/time.c
++++ b/arch/s390/kernel/time.c
+@@ -66,6 +66,25 @@ unsigned long long notrace __kprobes sch
+ return tod_to_ns(get_clock_monotonic());
+ }
+
++unsigned char ptff_function_mask[16];
++unsigned long lpar_offset;
++
++/*
++ * Get time offsets with PTFF
++ */
++void __init ptff_init(void)
++{
++ struct ptff_qto qto;
++
++ if (!test_facility(28))
++ return;
++ ptff(&ptff_function_mask, sizeof(ptff_function_mask), PTFF_QAF);
++
++ /* get LPAR offset */
++ if (ptff_query(PTFF_QTO) && ptff(&qto, sizeof(qto), PTFF_QTO) == 0)
++ lpar_offset = qto.tod_epoch_difference;
++}
++
+ /*
+ * Monotonic_clock - returns # of nanoseconds passed since time_init()
+ */
+@@ -318,11 +337,11 @@ static unsigned long clock_sync_flags;
+ #define CLOCK_SYNC_STP 3
+
+ /*
+- * The synchronous get_clock function. It will write the current clock
+- * value to the clock pointer and return 0 if the clock is in sync with
+- * the external time source. If the clock mode is local it will return
+- * -ENOSYS and -EAGAIN if the clock is not in sync with the external
+- * reference.
++ * The get_clock function for the physical clock. It will get the current
++ * TOD clock, subtract the LPAR offset and write the result to *clock.
++ * The function returns 0 if the clock is in sync with the external time
++ * source. If the clock mode is local it will return -EOPNOTSUPP and
++ * -EAGAIN if the clock is not in sync with the external reference.
+ */
+ int get_sync_clock(unsigned long long *clock)
+ {
+@@ -331,7 +350,7 @@ int get_sync_clock(unsigned long long *c
+
+ sw_ptr = &get_cpu_var(clock_sync_word);
+ sw0 = atomic_read(sw_ptr);
+- *clock = get_clock();
++ *clock = get_clock() - lpar_offset;
+ sw1 = atomic_read(sw_ptr);
+ put_cpu_var(clock_sync_word);
+ if (sw0 == sw1 && (sw0 & 0x80000000U))
+@@ -733,6 +752,7 @@ static int etr_sync_clock(void *data)
+ unsigned long long clock, old_clock, delay, delta;
+ struct clock_sync_data *etr_sync;
+ struct etr_aib *sync_port, *aib;
++ struct ptff_qto qto;
+ int port;
+ int rc;
+
+@@ -776,6 +796,10 @@ static int etr_sync_clock(void *data)
+ etr_sync->in_sync = -EAGAIN;
+ rc = -EAGAIN;
+ } else {
++ if (ptff_query(PTFF_QTO) &&
++ ptff(&qto, sizeof(qto), PTFF_QTO) == 0)
++ /* Update LPAR offset */
++ lpar_offset = qto.tod_epoch_difference;
+ etr_sync->in_sync = 1;
+ rc = 0;
+ }
+@@ -1505,6 +1529,7 @@ static int stp_sync_clock(void *data)
+ static int first;
+ unsigned long long old_clock, delta;
+ struct clock_sync_data *stp_sync;
++ struct ptff_qto qto;
+ int rc;
+
+ stp_sync = data;
+@@ -1529,6 +1554,10 @@ static int stp_sync_clock(void *data)
+ rc = chsc_sstpc(stp_page, STP_OP_SYNC, 0);
+ if (rc == 0) {
+ delta = adjust_time(old_clock, get_clock(), 0);
++ if (ptff_query(PTFF_QTO) &&
++ ptff(&qto, sizeof(qto), PTFF_QTO) == 0)
++ /* Update LPAR offset */
++ lpar_offset = qto.tod_epoch_difference;
+ fixup_clock_comparator(delta);
+ rc = chsc_sstpi(stp_page, &stp_info,
+ sizeof(struct stp_sstpi));
diff --git a/patches.arch/s390-sles11sp4-15-02-zfcp-fix-ELS-GS-request-response-length-for-hardware.patch b/patches.arch/s390-sles11sp4-15-02-zfcp-fix-ELS-GS-request-response-length-for-hardware.patch
new file mode 100644
index 0000000000..3d66ded32b
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-02-zfcp-fix-ELS-GS-request-response-length-for-hardware.patch
@@ -0,0 +1,142 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: fix ELS/GS request&response length for hardware data router
+Patch-mainline: v4.9-rc1
+Git-commit: 70369f8e15b220f50a16348c79a61d3f7054813c
+References: bnc#1003677, LTC#144308
+
+Description: zfcp: fix ELS/GS request&response length for hardware data router
+Symptom: The FCP channel rejects otherwise valid ELS requests with
+ FSF_REQUEST_SIZE_TOO_LARGE.
+ Such ELS requests can be issued by user space through BSG/HBAAPI,
+ or zfcp itself uses ADISC ELS for remote port link test on RSCN.
+ The latter can cause a short path outage due to
+ unnecessary remote target port recovery because the always
+ failing ADISC cannot detect extremely short path interruptions
+ beyond the local FCP channel.
+ Below example is decoded with zfcpdbf from s390-tools:
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : zfcp_dbf_san_req+0408
+ Record id : 1
+ Tag : fssels1
+ Request id : 0x<reqid>
+ Destination ID : 0x00<target d_id>
+ Payload info : 52000000 00000000 <our wwpn > [ADISC]
+ <our wwnn > 00<s_id> 00000000
+ 00000000 00000000 00000000 00000000
+ |
+ Timestamp : ...
+ Area : HBA
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : zfcp_dbf_hba_fsf_res+0740
+ Record id : 1
+ Tag : fs_ferr
+ Request id : 0x<reqid>
+ Request status : 0x00000010
+ FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS]
+ FSF sequence no: 0x...
+ FSF issued : ...
+ FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE]
+ FSF stat qual : 00000000 00000000 00000000 00000000
+ Prot stat : 0x00000100
+ Prot stat qual : 00000000 00000000 00000000 00000000
+Problem: In the hardware data router case, introduced with upstream
+ commit 86a9668a8d29ea711613e1cb37efa68e7c4db564
+ [SCSI] zfcp: support for hardware data router
+ the ELS/GS request&response length was not initialized.
+Solution: Initialize ELS/GS request&response length for the
+ hardware data router case as in the chained SBAL case.
+Reproduction: Pull&replug a cable in the SAN fabric beyond the switch adjacent
+ to the FCP channel, e.g. a cable to an open storage target port.
+
+Upstream-Description:
+
+ zfcp: fix ELS/GS request&response length for hardware data router
+
+ In the hardware data router case, introduced with kernel 3.2
+ commit 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router")
+ the ELS/GS request&response length needs to be initialized
+ as in the chained SBAL case.
+
+ Otherwise, the FCP channel rejects ELS requests with
+ FSF_REQUEST_SIZE_TOO_LARGE.
+
+ Such ELS requests can be issued by user space through BSG / HBA API,
+ or zfcp itself uses ADISC ELS for remote port link test on RSCN.
+ The latter can cause a short path outage due to
+ unnecessary remote target port recovery because the always
+ failing ADISC cannot detect extremely short path interruptions
+ beyond the local FCP channel.
+
+ Below example is decoded with zfcpdbf from s390-tools:
+
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : zfcp_dbf_san_req+0408
+ Record id : 1
+ Tag : fssels1
+ Request id : 0x<reqid>
+ Destination ID : 0x00<target d_id>
+ Payload info : 52000000 00000000 <our wwpn > [ADISC]
+ <our wwnn > 00<s_id> 00000000
+ 00000000 00000000 00000000 00000000
+
+ Timestamp : ...
+ Area : HBA
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : zfcp_dbf_hba_fsf_res+0740
+ Record id : 1
+ Tag : fs_ferr
+ Request id : 0x<reqid>
+ Request status : 0x00000010
+ FSF cmnd : 0x0000000b [FSF_QTCB_SEND_ELS]
+ FSF sequence no: 0x...
+ FSF issued : ...
+ FSF stat : 0x00000061 [FSF_REQUEST_SIZE_TOO_LARGE]
+ FSF stat qual : 00000000 00000000 00000000 00000000
+ Prot stat : 0x00000100
+ Prot stat qual : 00000000 00000000 00000000 00000000
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: 86a9668a8d29 ("[SCSI] zfcp: support for hardware data router")
+ Cc: <stable@vger.kernel.org> # 3.2+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_fsf.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/s390/scsi/zfcp_fsf.c
++++ b/drivers/s390/scsi/zfcp_fsf.c
+@@ -990,8 +990,12 @@ static int zfcp_fsf_setup_ct_els_sbals(s
+ if (zfcp_adapter_multi_buffer_active(adapter)) {
+ if (zfcp_qdio_sbals_from_sg(qdio, &req->qdio_req, sg_req))
+ return -EIO;
++ qtcb->bottom.support.req_buf_length =
++ zfcp_qdio_real_bytes(sg_req);
+ if (zfcp_qdio_sbals_from_sg(qdio, &req->qdio_req, sg_resp))
+ return -EIO;
++ qtcb->bottom.support.resp_buf_length =
++ zfcp_qdio_real_bytes(sg_resp);
+
+ zfcp_qdio_set_data_div(qdio, &req->qdio_req,
+ zfcp_qdio_sbale_count(sg_req));
diff --git a/patches.arch/s390-sles11sp4-15-03-zfcp-close-window-with-unblocked-rport-during-rport-.patch b/patches.arch/s390-sles11sp4-15-03-zfcp-close-window-with-unblocked-rport-during-rport-.patch
new file mode 100644
index 0000000000..cdb088164a
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-03-zfcp-close-window-with-unblocked-rport-during-rport-.patch
@@ -0,0 +1,188 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: close window with unblocked rport during rport gone
+Patch-mainline: v4.9-rc1
+Git-commit: 4eeaa4f3f1d6c47b69f70e222297a4df4743363e
+References: bnc#1003677, LTC#144310
+
+Description: zfcp: close window with unblocked rport during rport gone
+Symptom: Path interruptions beyond the host adjacent SAN switch,
+ i.e. near the storage side, cause unnecessary SCSI command
+ timeouts triggering scsi_eh (SCSI midlayer error handling).
+
+ Also, unnecessary and repeated DID_IMM_RETRY SCSI results for
+ pending and undesired new requests can occur.
+
+ As follow-on errors with scsi_eh, it can cause,
+ in the worst case, permanently lost paths due to one of:
+ sd <scsidev>: [<scsidisk>] Medium access timeout failure. \
+ Offlining disk!
+ sd <scsidev>: Device offlined - not ready after \
+ error recovery
+Problem: On a successful end of reopen port forced,
+ zfcp_erp_strategy_followup_success() re-uses the port
+ erp_action and the subsequent zfcp_erp_action_cleanup() now
+ sees ZFCP_ERP_SUCCEEDED with
+ erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT
+ erroneously unblocking the rport with
+ zfcp_scsi_schedule_rport_register().
+
+ This opens a time window with unblocked rport (until the
+ followup port reopen recovery would block it again).
+ If a scsi_cmnd timeout occurs during this time window
+ fc_timed_out() cannot work as desired and such command
+ would indeed time out and trigger scsi_eh. This prevents
+ a clean and timely path failover.
+ This should not happen if the path issue can be recovered
+ on FC transport layer such as path issues involving RSCNs.
+
+ DID_IMM_RETRY can occur because internally zfcp still
+ has its zfcp_port correctly blocked during the time window.
+Solution: Detect this situation with the fresh port reopen erp_action
+ being in its very first step ZFCP_ERP_STEP_UNINITIALIZED
+ and do not perform zfcp_scsi_schedule_rport_register().
+
+ For fix validation and to aid future debugging with other
+ recoveries we now also trace (un)blocking of rports.
+Reproduction: Perform cable pull/replug beyond the host adjacent switch
+ or SAN switch port off/on at the storage side.
+ Use randomized off durations similar to the SCSI command
+ timeout value.
+
+Upstream-Description:
+
+ zfcp: close window with unblocked rport during rport gone
+
+ On a successful end of reopen port forced,
+ zfcp_erp_strategy_followup_success() re-uses the port erp_action
+ and the subsequent zfcp_erp_action_cleanup() now
+ sees ZFCP_ERP_SUCCEEDED with
+ erp_action->action==ZFCP_ERP_ACTION_REOPEN_PORT
+ instead of ZFCP_ERP_ACTION_REOPEN_PORT_FORCED
+ but must not perform zfcp_scsi_schedule_rport_register().
+
+ We can detect this because the fresh port reopen erp_action
+ is in its very first step ZFCP_ERP_STEP_UNINITIALIZED.
+
+ Otherwise this opens a time window with unblocked rport
+ (until the followup port reopen recovery would block it again).
+ If a scsi_cmnd timeout occurs during this time window
+ fc_timed_out() cannot work as desired and such command
+ would indeed time out and trigger scsi_eh. This prevents
+ a clean and timely path failover.
+ This should not happen if the path issue can be recovered
+ on FC transport layer such as path issues involving RSCNs.
+
+ Also, unnecessary and repeated DID_IMM_RETRY for pending and
+ undesired new requests occur because internally zfcp still
+ has its zfcp_port blocked.
+
+ As follow-on errors with scsi_eh, it can cause,
+ in the worst case, permanently lost paths due to one of:
+ sd <scsidev>: [<scsidisk>] Medium access timeout failure. Offlining disk!
+ sd <scsidev>: Device offlined - not ready after error recovery
+
+ For fix validation and to aid future debugging with other recoveries
+ we now also trace (un)blocking of rports.
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: 5767620c383a ("[SCSI] zfcp: Do not unblock rport from REOPEN_PORT_FORCED")
+ Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
+ Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
+ Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
+ Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
+ Cc: <stable@vger.kernel.org> #2.6.32+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.h | 7 ++++++-
+ drivers/s390/scsi/zfcp_erp.c | 12 +++++++++---
+ drivers/s390/scsi/zfcp_scsi.c | 8 +++++++-
+ 3 files changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.h
++++ b/drivers/s390/scsi/zfcp_dbf.h
+@@ -2,7 +2,7 @@
+ * zfcp device driver
+ * debug feature declarations
+ *
+- * Copyright IBM Corp. 2008, 2010
++ * Copyright IBM Corp. 2008, 2015
+ */
+
+ #ifndef ZFCP_DBF_H
+@@ -17,6 +17,11 @@
+
+ #define ZFCP_DBF_INVALID_LUN 0xFFFFFFFFFFFFFFFFull
+
++enum zfcp_dbf_pseudo_erp_act_type {
++ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD = 0xff,
++ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL = 0xfe,
++};
++
+ /**
+ * struct zfcp_dbf_rec_trigger - trace record for triggered recovery action
+ * @ready: number of ready recovery actions
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -3,7 +3,7 @@
+ *
+ * Error Recovery Procedures (ERP).
+ *
+- * Copyright IBM Corporation 2002, 2010
++ * Copyright IBM Corp. 2002, 2015
+ */
+
+ #define KMSG_COMPONENT "zfcp"
+@@ -1225,8 +1225,14 @@ static void zfcp_erp_action_cleanup(stru
+ break;
+
+ case ZFCP_ERP_ACTION_REOPEN_PORT:
+- if (result == ZFCP_ERP_SUCCEEDED)
+- zfcp_scsi_schedule_rport_register(port);
++ /* This switch case might also happen after a forced reopen
++ * was successfully done and thus overwritten with a new
++ * non-forced reopen at `ersfs_2'. In this case, we must not
++ * do the clean-up of the non-forced version.
++ */
++ if (act->step != ZFCP_ERP_STEP_UNINITIALIZED)
++ if (result == ZFCP_ERP_SUCCEEDED)
++ zfcp_scsi_schedule_rport_register(port);
+ /* fall through */
+ case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
+ put_device(&port->dev);
+--- a/drivers/s390/scsi/zfcp_scsi.c
++++ b/drivers/s390/scsi/zfcp_scsi.c
+@@ -3,7 +3,7 @@
+ *
+ * Interface to Linux SCSI midlayer.
+ *
+- * Copyright IBM Corporation 2002, 2010
++ * Copyright IBM Corp. 2002, 2015
+ */
+
+ #define KMSG_COMPONENT "zfcp"
+@@ -571,6 +571,9 @@ static void zfcp_scsi_rport_register(str
+ ids.port_id = port->d_id;
+ ids.roles = FC_RPORT_ROLE_FCP_TARGET;
+
++ zfcp_dbf_rec_trig("scpaddy", port->adapter, port, NULL,
++ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD,
++ ZFCP_PSEUDO_ERP_ACTION_RPORT_ADD);
+ rport = fc_remote_port_add(port->adapter->scsi_host, 0, &ids);
+ if (!rport) {
+ dev_err(&port->adapter->ccw_device->dev,
+@@ -592,6 +595,9 @@ static void zfcp_scsi_rport_block(struct
+ struct fc_rport *rport = port->rport;
+
+ if (rport) {
++ zfcp_dbf_rec_trig("scpdely", port->adapter, port, NULL,
++ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL,
++ ZFCP_PSEUDO_ERP_ACTION_RPORT_DEL);
+ fc_remote_port_delete(rport);
+ port->rport = NULL;
+ }
diff --git a/patches.arch/s390-sles11sp4-15-04-01-zfcp-retain-trace-level-for-SCSI-and-HBA-FSF-respons.patch b/patches.arch/s390-sles11sp4-15-04-01-zfcp-retain-trace-level-for-SCSI-and-HBA-FSF-respons.patch
new file mode 100644
index 0000000000..7e6a903d20
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-01-zfcp-retain-trace-level-for-SCSI-and-HBA-FSF-respons.patch
@@ -0,0 +1,260 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: retain trace level for SCSI and HBA FSF response records
+Patch-mainline: v4.9-rc1
+Git-commit: 35f040df97fa0e94c7851c054ec71533c88b4b81
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: retain trace level for SCSI and HBA FSF response records
+
+ While retaining the actual filtering according to trace level,
+ the following commits started to write such filtered records
+ with a hardcoded record level of 1 instead of the actual record level:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+
+ Now we can distinguish written records again for offline level filtering.
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: 250a1352b95e ("[SCSI] zfcp: Redesign of the debug tracing for SCSI records.")
+ Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 11 ++++++-----
+ drivers/s390/scsi/zfcp_dbf.h | 4 ++--
+ drivers/s390/scsi/zfcp_ext.h | 7 ++++---
+ 3 files changed, 12 insertions(+), 10 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -3,7 +3,7 @@
+ *
+ * Debug traces for zfcp.
+ *
+- * Copyright IBM Corporation 2002, 2010
++ * Copyright IBM Corp. 2002, 2015
+ */
+
+ #define KMSG_COMPONENT "zfcp"
+@@ -57,7 +57,7 @@ void zfcp_dbf_pl_write(struct zfcp_dbf *
+ * @tag: tag indicating which kind of unsolicited status has been received
+ * @req: request for which a response was received
+ */
+-void zfcp_dbf_hba_fsf_res(char *tag, struct zfcp_fsf_req *req)
++void zfcp_dbf_hba_fsf_res(char *tag, int level, struct zfcp_fsf_req *req)
+ {
+ struct zfcp_dbf *dbf = req->adapter->dbf;
+ struct fsf_qtcb_prefix *q_pref = &req->qtcb->prefix;
+@@ -89,7 +89,7 @@ void zfcp_dbf_hba_fsf_res(char *tag, str
+ rec->pl_len, "fsf_res", req->req_id);
+ }
+
+- debug_event(dbf->hba, 1, rec, sizeof(*rec));
++ debug_event(dbf->hba, level, rec, sizeof(*rec));
+ spin_unlock_irqrestore(&dbf->hba_lock, flags);
+ }
+
+@@ -391,7 +391,8 @@ void zfcp_dbf_san_in_els(char *tag, stru
+ * @sc: pointer to struct scsi_cmnd
+ * @fsf: pointer to struct zfcp_fsf_req
+ */
+-void zfcp_dbf_scsi(char *tag, struct scsi_cmnd *sc, struct zfcp_fsf_req *fsf)
++void zfcp_dbf_scsi(char *tag, int level, struct scsi_cmnd *sc,
++ struct zfcp_fsf_req *fsf)
+ {
+ struct zfcp_adapter *adapter =
+ (struct zfcp_adapter *) sc->device->host->hostdata[0];
+@@ -433,7 +434,7 @@ void zfcp_dbf_scsi(char *tag, struct scs
+ }
+ }
+
+- debug_event(dbf->scsi, 1, rec, sizeof(*rec));
++ debug_event(dbf->scsi, level, rec, sizeof(*rec));
+ spin_unlock_irqrestore(&dbf->scsi_lock, flags);
+ }
+
+--- a/drivers/s390/scsi/zfcp_dbf.h
++++ b/drivers/s390/scsi/zfcp_dbf.h
+@@ -284,7 +284,7 @@ static inline
+ void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
+ {
+ if (level <= req->adapter->dbf->hba->level)
+- zfcp_dbf_hba_fsf_res(tag, req);
++ zfcp_dbf_hba_fsf_res(tag, level, req);
+ }
+
+ /**
+@@ -323,7 +323,7 @@ void _zfcp_dbf_scsi(char *tag, int level
+ scmd->device->host->hostdata[0];
+
+ if (level <= adapter->dbf->scsi->level)
+- zfcp_dbf_scsi(tag, scmd, req);
++ zfcp_dbf_scsi(tag, level, scmd, req);
+ }
+
+ /**
+--- a/drivers/s390/scsi/zfcp_ext.h
++++ b/drivers/s390/scsi/zfcp_ext.h
+@@ -3,7 +3,7 @@
+ *
+ * External function declarations.
+ *
+- * Copyright IBM Corporation 2002, 2010
++ * Copyright IBM Corp. 2002, 2015
+ */
+
+ #ifndef ZFCP_EXT_H
+@@ -50,7 +50,7 @@ extern void zfcp_dbf_rec_trig(char *, st
+ struct zfcp_port *, struct scsi_device *, u8, u8);
+ extern void zfcp_dbf_rec_run(char *, struct zfcp_erp_action *);
+ extern void zfcp_dbf_hba_fsf_uss(char *, struct zfcp_fsf_req *);
+-extern void zfcp_dbf_hba_fsf_res(char *, struct zfcp_fsf_req *);
++extern void zfcp_dbf_hba_fsf_res(char *, int, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_hba_bit_err(char *, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_hba_berr(struct zfcp_dbf *, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_hba_def_err(struct zfcp_adapter *, u64, u16, void **);
+@@ -58,7 +58,8 @@ extern void zfcp_dbf_hba_basic(char *, s
+ extern void zfcp_dbf_san_req(char *, struct zfcp_fsf_req *, u32);
+ extern void zfcp_dbf_san_res(char *, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_san_in_els(char *, struct zfcp_fsf_req *);
+-extern void zfcp_dbf_scsi(char *, struct scsi_cmnd *, struct zfcp_fsf_req *);
++extern void zfcp_dbf_scsi(char *, int, struct scsi_cmnd *,
++ struct zfcp_fsf_req *);
+
+ /* zfcp_erp.c */
+ extern void zfcp_erp_set_adapter_status(struct zfcp_adapter *, u32);
diff --git a/patches.arch/s390-sles11sp4-15-04-02-zfcp-restore-Dont-use-0-to-indicate-invalid-LUN-in-r.patch b/patches.arch/s390-sles11sp4-15-04-02-zfcp-restore-Dont-use-0-to-indicate-invalid-LUN-in-r.patch
new file mode 100644
index 0000000000..27300f559c
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-02-zfcp-restore-Dont-use-0-to-indicate-invalid-LUN-in-r.patch
@@ -0,0 +1,168 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace
+Patch-mainline: v4.9-rc1
+Git-commit: 0102a30a6ff60f4bb4c07358ca3b1f92254a6c25
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace
+
+ bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ ("[SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace")
+ which was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -233,7 +233,8 @@ static void zfcp_dbf_set_common(struct z
+ if (sdev) {
+ rec->lun_status = atomic_read(&sdev_to_zfcp(sdev)->status);
+ rec->lun = zfcp_scsi_dev_lun(sdev);
+- }
++ } else
++ rec->lun = ZFCP_DBF_INVALID_LUN;
+ }
+
+ /**
diff --git a/patches.arch/s390-sles11sp4-15-04-03-zfcp-trace-on-request-for-open-and-close-of-WKA-port.patch b/patches.arch/s390-sles11sp4-15-04-03-zfcp-trace-on-request-for-open-and-close-of-WKA-port.patch
new file mode 100644
index 0000000000..371a447b1d
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-03-zfcp-trace-on-request-for-open-and-close-of-WKA-port.patch
@@ -0,0 +1,249 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: trace on request for open and close of WKA port
+Patch-mainline: v4.9-rc1
+Git-commit: d27a7cb91960cf1fdd11b10071e601828cbf4b1f
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: trace on request for open and close of WKA port
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+ HBA records no longer contain WWPN, D_ID, or LUN
+ to reduce duplicate information which is already in REC records.
+ In contrast to "regular" target ports, we don't use recovery to open
+ WKA ports such as directory/nameserver, so we don't get REC records.
+ Therefore, introduce pseudo REC running records without any
+ actual recovery action but including D_ID of WKA port on open/close.
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 32 ++++++++++++++++++++++++++++++++
+ drivers/s390/scsi/zfcp_ext.h | 1 +
+ drivers/s390/scsi/zfcp_fsf.c | 8 ++++++--
+ 3 files changed, 39 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -313,6 +313,38 @@ void zfcp_dbf_rec_run(char *tag, struct
+ spin_unlock_irqrestore(&dbf->rec_lock, flags);
+ }
+
++/**
++ * zfcp_dbf_rec_run_wka - trace wka port event with info like running recovery
++ * @tag: identifier for event
++ * @wka_port: well known address port
++ * @req_id: request ID to correlate with potential HBA trace record
++ */
++void zfcp_dbf_rec_run_wka(char *tag, struct zfcp_fc_wka_port *wka_port,
++ u64 req_id)
++{
++ struct zfcp_dbf *dbf = wka_port->adapter->dbf;
++ struct zfcp_dbf_rec *rec = &dbf->rec_buf;
++ unsigned long flags;
++
++ spin_lock_irqsave(&dbf->rec_lock, flags);
++ memset(rec, 0, sizeof(*rec));
++
++ rec->id = ZFCP_DBF_REC_RUN;
++ memcpy(rec->tag, tag, ZFCP_DBF_TAG_LEN);
++ rec->port_status = wka_port->status;
++ rec->d_id = wka_port->d_id;
++ rec->lun = ZFCP_DBF_INVALID_LUN;
++
++ rec->u.run.fsf_req_id = req_id;
++ rec->u.run.rec_status = ~0;
++ rec->u.run.rec_step = ~0;
++ rec->u.run.rec_action = ~0;
++ rec->u.run.rec_count = ~0;
++
++ debug_event(dbf->rec, 1, rec, sizeof(*rec));
++ spin_unlock_irqrestore(&dbf->rec_lock, flags);
++}
++
+ static inline
+ void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf, void *data, u8 id, u16 len,
+ u64 req_id, u32 d_id)
+--- a/drivers/s390/scsi/zfcp_ext.h
++++ b/drivers/s390/scsi/zfcp_ext.h
+@@ -49,6 +49,7 @@ extern void zfcp_dbf_adapter_unregister(
+ extern void zfcp_dbf_rec_trig(char *, struct zfcp_adapter *,
+ struct zfcp_port *, struct scsi_device *, u8, u8);
+ extern void zfcp_dbf_rec_run(char *, struct zfcp_erp_action *);
++extern void zfcp_dbf_rec_run_wka(char *, struct zfcp_fc_wka_port *, u64);
+ extern void zfcp_dbf_hba_fsf_uss(char *, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_hba_fsf_res(char *, int, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_hba_bit_err(char *, struct zfcp_fsf_req *);
+--- a/drivers/s390/scsi/zfcp_fsf.c
++++ b/drivers/s390/scsi/zfcp_fsf.c
+@@ -1605,7 +1605,7 @@ out:
+ int zfcp_fsf_open_wka_port(struct zfcp_fc_wka_port *wka_port)
+ {
+ struct zfcp_qdio *qdio = wka_port->adapter->qdio;
+- struct zfcp_fsf_req *req;
++ struct zfcp_fsf_req *req = NULL;
+ int retval = -EIO;
+
+ spin_lock_irq(&qdio->req_q_lock);
+@@ -1634,6 +1634,8 @@ int zfcp_fsf_open_wka_port(struct zfcp_f
+ zfcp_fsf_req_free(req);
+ out:
+ spin_unlock_irq(&qdio->req_q_lock);
++ if (req && !IS_ERR(req))
++ zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
+ return retval;
+ }
+
+@@ -1658,7 +1660,7 @@ static void zfcp_fsf_close_wka_port_hand
+ int zfcp_fsf_close_wka_port(struct zfcp_fc_wka_port *wka_port)
+ {
+ struct zfcp_qdio *qdio = wka_port->adapter->qdio;
+- struct zfcp_fsf_req *req;
++ struct zfcp_fsf_req *req = NULL;
+ int retval = -EIO;
+
+ spin_lock_irq(&qdio->req_q_lock);
+@@ -1687,6 +1689,8 @@ int zfcp_fsf_close_wka_port(struct zfcp_
+ zfcp_fsf_req_free(req);
+ out:
+ spin_unlock_irq(&qdio->req_q_lock);
++ if (req && !IS_ERR(req))
++ zfcp_dbf_rec_run_wka("fscwp_1", wka_port, req->req_id);
+ return retval;
+ }
+
diff --git a/patches.arch/s390-sles11sp4-15-04-04-zfcp-restore-tracing-of-handle-for-port-and-LUN-with.patch b/patches.arch/s390-sles11sp4-15-04-04-zfcp-restore-tracing-of-handle-for-port-and-LUN-with.patch
new file mode 100644
index 0000000000..bbb1739b4b
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-04-zfcp-restore-tracing-of-handle-for-port-and-LUN-with.patch
@@ -0,0 +1,177 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: restore tracing of handle for port and LUN with HBA records
+Patch-mainline: v4.9-rc1
+Git-commit: 7c964ffe586bc0c3d9febe9bf97a2e4b2866e5b7
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: restore tracing of handle for port and LUN with HBA records
+
+ This information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+ but is required to debug e.g. invalid handle situations.
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 2 ++
+ drivers/s390/scsi/zfcp_dbf.h | 2 ++
+ 2 files changed, 4 insertions(+)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -77,6 +77,8 @@ void zfcp_dbf_hba_fsf_res(char *tag, int
+ rec->u.res.req_issued = req->issued;
+ rec->u.res.prot_status = q_pref->prot_status;
+ rec->u.res.fsf_status = q_head->fsf_status;
++ rec->u.res.port_handle = q_head->port_handle;
++ rec->u.res.lun_handle = q_head->lun_handle;
+
+ memcpy(rec->u.res.prot_status_qual, &q_pref->prot_status_qual,
+ FSF_PROT_STATUS_QUAL_SIZE);
+--- a/drivers/s390/scsi/zfcp_dbf.h
++++ b/drivers/s390/scsi/zfcp_dbf.h
+@@ -131,6 +131,8 @@ struct zfcp_dbf_hba_res {
+ u8 prot_status_qual[FSF_PROT_STATUS_QUAL_SIZE];
+ u32 fsf_status;
+ u8 fsf_status_qual[FSF_STATUS_QUALIFIER_SIZE];
++ u32 port_handle;
++ u32 lun_handle;
+ } __packed;
+
+ /**
diff --git a/patches.arch/s390-sles11sp4-15-04-05-zfcp-fix-D_ID-field-with-actual-value-on-tracing-SAN.patch b/patches.arch/s390-sles11sp4-15-04-05-zfcp-fix-D_ID-field-with-actual-value-on-tracing-SAN.patch
new file mode 100644
index 0000000000..5c9d9a0e37
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-05-zfcp-fix-D_ID-field-with-actual-value-on-tracing-SAN.patch
@@ -0,0 +1,224 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: fix D_ID field with actual value on tracing SAN responses
+Patch-mainline: v4.9-rc1
+Git-commit: 771bf03537ddfa4a4dde62ef9dfbc82e4f77ab20
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: fix D_ID field with actual value on tracing SAN responses
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ ("[SCSI] zfcp: Simplify handling of ct and els requests")
+ we lost the N_Port-ID where a CT response comes from.
+ It's especially useful if the request SAN trace record
+ with D_ID was already lost due to trace buffer wrap.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and
+ only for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els
+ and fill it in on request to use in SAN response trace.
+ Strictly speaking the D_ID on SAN response is the FC frame's S_ID.
+ We don't need a field for the other end which is always us.
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
+ Fixes: 7c7dc196814b ("[SCSI] zfcp: Simplify handling of ct and els requests")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 2 +-
+ drivers/s390/scsi/zfcp_fsf.c | 2 ++
+ drivers/s390/scsi/zfcp_fsf.h | 4 +++-
+ 3 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -399,7 +399,7 @@ void zfcp_dbf_san_res(char *tag, struct
+
+ length = (u16)(ct_els->resp->length + FC_CT_HDR_LEN);
+ zfcp_dbf_san(tag, dbf, sg_virt(ct_els->resp), ZFCP_DBF_SAN_RES, length,
+- fsf->req_id, 0);
++ fsf->req_id, ct_els->d_id);
+ }
+
+ /**
+--- a/drivers/s390/scsi/zfcp_fsf.c
++++ b/drivers/s390/scsi/zfcp_fsf.c
+@@ -1085,6 +1085,7 @@ int zfcp_fsf_send_ct(struct zfcp_fc_wka_
+
+ req->handler = zfcp_fsf_send_ct_handler;
+ req->qtcb->header.port_handle = wka_port->handle;
++ ct->d_id = wka_port->d_id;
+ req->data = ct;
+
+ zfcp_dbf_san_req("fssct_1", req, wka_port->d_id);
+@@ -1188,6 +1189,7 @@ int zfcp_fsf_send_els(struct zfcp_adapte
+
+ hton24(req->qtcb->bottom.support.d_id, d_id);
+ req->handler = zfcp_fsf_send_els_handler;
++ els->d_id = d_id;
+ req->data = els;
+
+ zfcp_dbf_san_req("fssels1", req, d_id);
+--- a/drivers/s390/scsi/zfcp_fsf.h
++++ b/drivers/s390/scsi/zfcp_fsf.h
+@@ -3,7 +3,7 @@
+ *
+ * Interface to the FSF support functions.
+ *
+- * Copyright IBM Corporation 2002, 2010
++ * Copyright IBM Corp. 2002, 2015
+ */
+
+ #ifndef FSF_H
+@@ -462,6 +462,7 @@ struct zfcp_blk_drv_data {
+ * @handler_data: data passed to handler function
+ * @port: Optional pointer to port for zfcp internal ELS (only test link ADISC)
+ * @status: used to pass error status to calling function
++ * @d_id: Destination ID of either open WKA port for CT or of D_ID for ELS
+ */
+ struct zfcp_fsf_ct_els {
+ struct scatterlist *req;
+@@ -470,6 +471,7 @@ struct zfcp_fsf_ct_els {
+ void *handler_data;
+ struct zfcp_port *port;
+ int status;
++ u32 d_id;
+ };
+
+ #endif /* FSF_H */
diff --git a/patches.arch/s390-sles11sp4-15-04-06-zfcp-fix-payload-trace-length-for-SAN-request-respon.patch b/patches.arch/s390-sles11sp4-15-04-06-zfcp-fix-payload-trace-length-for-SAN-request-respon.patch
new file mode 100644
index 0000000000..e4f337882d
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-06-zfcp-fix-payload-trace-length-for-SAN-request-respon.patch
@@ -0,0 +1,209 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: fix payload trace length for SAN request&response
+Patch-mainline: v4.9-rc1
+Git-commit: 94db3725f049ead24c96226df4a4fb375b880a77
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: fix payload trace length for SAN request&response
+
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp
+ is the largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within bounds
+ due to the padding of the union or
+ due to the trace capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -381,7 +381,7 @@ void zfcp_dbf_san_req(char *tag, struct
+ struct zfcp_fsf_ct_els *ct_els = fsf->data;
+ u16 length;
+
+- length = (u16)(ct_els->req->length + FC_CT_HDR_LEN);
++ length = (u16)(ct_els->req->length);
+ zfcp_dbf_san(tag, dbf, sg_virt(ct_els->req), ZFCP_DBF_SAN_REQ, length,
+ fsf->req_id, d_id);
+ }
+@@ -397,7 +397,7 @@ void zfcp_dbf_san_res(char *tag, struct
+ struct zfcp_fsf_ct_els *ct_els = fsf->data;
+ u16 length;
+
+- length = (u16)(ct_els->resp->length + FC_CT_HDR_LEN);
++ length = (u16)(ct_els->resp->length);
+ zfcp_dbf_san(tag, dbf, sg_virt(ct_els->resp), ZFCP_DBF_SAN_RES, length,
+ fsf->req_id, ct_els->d_id);
+ }
diff --git a/patches.arch/s390-sles11sp4-15-04-07-zfcp-trace-full-payload-of-all-SAN-records-req-resp-.patch b/patches.arch/s390-sles11sp4-15-04-07-zfcp-trace-full-payload-of-all-SAN-records-req-resp-.patch
new file mode 100644
index 0000000000..2d1783b703
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-07-zfcp-trace-full-payload-of-all-SAN-records-req-resp-.patch
@@ -0,0 +1,338 @@
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Subject: zfcp: trace full payload of all SAN records (req,resp,iels)
+Patch-mainline: v4.9-rc1
+Git-commit: aceeffbb59bb91404a0bda32a542d7ebf878433a
+References: bnc#1003677, LTC#144312
+
+Description: zfcp: fix tracing regressions
+Symptom: Cannot distinguish trace level of trace records written with
+ different trace levels.
+
+ RECovery trace records do not show obviously if the LUN
+ record field has a valid value or is n/a.
+
+ Cannot interpret HBA error trace records for failed port
+ actions, if it's for WKA (well known address) ports such as
+ the fabric nameserver used for zfcp auto port scan.
+
+ Cannot debug invalid handle situations with ports or LUNs.
+
+ Especially if a request SAN trace record was lost due to
+ trace buffer wrapping, we cannot see from which N_Port-ID the
+ corresponding SAN response came from.
+
+ Wrong payload length and confusing random payload data for
+ RSPN (register symbolic port name) FC-GS responses
+ (SAN trace area response tag: fsscth2).
+
+ Cannot debug issues with larger SAN requests/responses
+ such as with zfcp auto port scan where we need to see
+ the currently active zone set.
+Problem: While retaining the actual filtering according to trace
+ level, the following commits started to write such
+ filtered records with a hardcoded record level of 1:
+ commit 250a1352b95e1db3216e5c5d4f4365bea5122f4a
+ [SCSI] zfcp: Redesign of the debug tracing for SCSI records.
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ Explicit marking of an invalid LUN was lost with
+ commit ae0904f60fab7cb20c48d32eefdd735e478b91fb
+ zfcp: Redesign of the debug tracing for recovery actions.
+
+ Since commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+ HBA records no longer contain WWPN, D_ID, or LUN to reduce
+ duplicate information which is already in REC records. In
+ contrast to "regular" target ports, we don't use recovery to
+ open WKA ports such as directory/nameserver, so we don't get
+ REC records.
+
+ Handle information was lost with
+ commit a54ca0f62f953898b05549391ac2a8a4dad6482b
+ [SCSI] zfcp: Redesign of the debug tracing for HBA records.
+
+ With commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ we lost the N_Port-ID where an ELS response comes from.
+ With commit 7c7dc196814b9e1d5cc254dc579a5fa78ae524f7
+ [SCSI] zfcp: Simplify handling of ct and els requests
+ we lost the N_Port-ID where a CT response comes from.
+
+ Commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+ started to add FC_CT_HDR_LEN which made zfcp dump random data
+ out of bounds for RSPN GS responses because u.rspn.rsp is the
+ largest and last field in the union of struct zfcp_fc_req.
+ Other request/response types only happened to stay within
+ bounds due to the padding of the union or due to the trace
+ capping of u.gspn.rsp to ZFCP_DBF_SAN_MAX_PAYLOAD.
+ |
+ Timestamp : ...
+ Area : SAN
+ Subarea : 00
+ Level : 1
+ Exception : -
+ CPU id : ..
+ Caller : ...
+ Record id : 2
+ Tag : fsscth2
+ Request id : 0x...
+ Destination ID : 0x00fffffc
+ Payload short : 01000000 fc020000 80020000 00000000
+ xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx <===
+ 00000000 00000000 00000000 00000000
+ Payload length : 32 <===
+ |
+ struct zfcp_fc_req {
+ [0] struct zfcp_fsf_ct_els ct_els;
+ [56] struct scatterlist sg_req;
+ [96] struct scatterlist sg_rsp;
+ union {
+ struct {req; rsp;} adisc; SIZE: 28+28= 56
+ struct {req; rsp;} gid_pn; SIZE: 24+20= 44
+ struct {rspsg; req;} gpn_ft; SIZE: 40*4+20=180
+ struct {req; rsp;} gspn; SIZE: 20+273= 293
+ struct {req; rsp;} rspn; SIZE: 277+16= 293
+ [136] } u;
+ }
+ SIZE: 432
+
+ The full payload of SAN trace records was lost with
+ commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ [SCSI] zfcp: Redesign of the debug tracing for SAN records.
+Solution: Write records with their actual record level.
+
+ Bring back
+ commit d21e9daa63e009ce5b87bbcaa6d11ce48e07bbbe
+ [SCSI] zfcp: Dont use 0 to indicate invalid LUN in rec trace.
+
+ Introduce pseudo REC running records without any actual
+ recovery action but including D_ID of WKA port on open/close.
+
+ Restore tracing of handle for port and LUN with HBA records.
+
+ GS uses an open WKA port handle and ELS just a D_ID, and only
+ for ELS we could get D_ID from QTCB bottom via zfcp_fsf_req.
+ To cover both cases, add a new field to zfcp_fsf_ct_els and
+ fill it in on request to use in SAN response trace. Strictly
+ speaking the D_ID on SAN response is the FC frame's S_ID. We
+ don't need a field for the other end which is always us.
+
+ Fix payload trace length for SAN request&response.
+
+ Trace full payload of all SAN records (req,resp,iels) in
+ associated PAYload trace record(s) if data spills SAN record.
+ For the large GPN_FT response (4 pages), save space by not
+ dumping any empty residual entries.
+Reproduction: Increase the trace level of the HBA and SCSI trace area to
+ the maximum of 6. Set an NPIV-enabled FCP device online in a
+ SAN zone with other initiator ports. Perform some I/O.
+
+Upstream-Description:
+
+ zfcp: trace full payload of all SAN records (req,resp,iels)
+
+ This was lost with commit 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
+ ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
+ but is necessary for problem determination, e.g. to see the
+ currently active zone set during automatic port scan.
+
+ For the large GPN_FT response (4 pages), save space by not dumping
+ any empty residual entries.
+
+ Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+ Fixes: 2c55b750a884 ("[SCSI] zfcp: Redesign of the debug tracing for SAN records.")
+ Cc: <stable@vger.kernel.org> #2.6.38+
+ Reviewed-by: Alexey Ishchuk <aishchuk@linux.vnet.ibm.com>
+ Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+ Reviewed-by: Hannes Reinecke <hare@suse.com>
+ Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 116 ++++++++++++++++++++++++++++++++++++++-----
+ drivers/s390/scsi/zfcp_dbf.h | 1
+ 2 files changed, 104 insertions(+), 13 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -3,7 +3,7 @@
+ *
+ * Debug traces for zfcp.
+ *
+- * Copyright IBM Corp. 2002, 2015
++ * Copyright IBM Corp. 2002, 2016
+ */
+
+ #define KMSG_COMPONENT "zfcp"
+@@ -348,12 +348,15 @@ void zfcp_dbf_rec_run_wka(char *tag, str
+ }
+
+ static inline
+-void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf, void *data, u8 id, u16 len,
+- u64 req_id, u32 d_id)
++void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf,
++ char *paytag, struct scatterlist *sg, u8 id, u16 len,
++ u64 req_id, u32 d_id, u16 cap_len)
+ {
+ struct zfcp_dbf_san *rec = &dbf->san_buf;
+ u16 rec_len;
+ unsigned long flags;
++ struct zfcp_dbf_pay *payload = &dbf->pay_buf;
++ u16 pay_sum = 0;
+
+ spin_lock_irqsave(&dbf->san_lock, flags);
+ memset(rec, 0, sizeof(*rec));
+@@ -361,10 +364,41 @@ void zfcp_dbf_san(char *tag, struct zfcp
+ rec->id = id;
+ rec->fsf_req_id = req_id;
+ rec->d_id = d_id;
+- rec_len = min(len, (u16)ZFCP_DBF_SAN_MAX_PAYLOAD);
+- memcpy(rec->payload, data, rec_len);
+ memcpy(rec->tag, tag, ZFCP_DBF_TAG_LEN);
++ rec->pl_len = len; /* full length even if we cap pay below */
++ if (!sg)
++ goto out;
++ rec_len = min_t(unsigned int, sg->length, ZFCP_DBF_SAN_MAX_PAYLOAD);
++ memcpy(rec->payload, sg_virt(sg), rec_len); /* part of 1st sg entry */
++ if (len <= rec_len)
++ goto out; /* skip pay record if full content in rec->payload */
++
++ /* if (len > rec_len):
++ * dump data up to cap_len ignoring small duplicate in rec->payload
++ */
++ spin_lock_irqsave(&dbf->pay_lock, flags);
++ memset(payload, 0, sizeof(*payload));
++ memcpy(payload->area, paytag, ZFCP_DBF_TAG_LEN);
++ payload->fsf_req_id = req_id;
++ payload->counter = 0;
++ for (; sg && pay_sum < cap_len; sg = sg_next(sg)) {
++ u16 pay_len, offset = 0;
++
++ while (offset < sg->length && pay_sum < cap_len) {
++ pay_len = min((u16)ZFCP_DBF_PAY_MAX_REC,
++ (u16)(sg->length - offset));
++ /* cap_len <= pay_sum < cap_len+ZFCP_DBF_PAY_MAX_REC */
++ memcpy(payload->data, sg_virt(sg) + offset, pay_len);
++ debug_event(dbf->pay, 1, payload,
++ zfcp_dbf_plen(pay_len));
++ payload->counter++;
++ offset += pay_len;
++ pay_sum += pay_len;
++ }
++ }
++ spin_unlock(&dbf->pay_lock);
+
++out:
+ debug_event(dbf->san, 1, rec, sizeof(*rec));
+ spin_unlock_irqrestore(&dbf->san_lock, flags);
+ }
+@@ -381,9 +415,62 @@ void zfcp_dbf_san_req(char *tag, struct
+ struct zfcp_fsf_ct_els *ct_els = fsf->data;
+ u16 length;
+
+- length = (u16)(ct_els->req->length);
+- zfcp_dbf_san(tag, dbf, sg_virt(ct_els->req), ZFCP_DBF_SAN_REQ, length,
+- fsf->req_id, d_id);
++ length = (u16)zfcp_qdio_real_bytes(ct_els->req);
++ zfcp_dbf_san(tag, dbf, "san_req", ct_els->req, ZFCP_DBF_SAN_REQ,
++ length, fsf->req_id, d_id, length);
++}
++
++static u16 zfcp_dbf_san_res_cap_len_if_gpn_ft(char *tag,
++ struct zfcp_fsf_req *fsf,
++ u16 len)
++{
++ struct zfcp_fsf_ct_els *ct_els = fsf->data;
++ struct fc_ct_hdr *reqh = sg_virt(ct_els->req);
++ struct fc_ns_gid_ft *reqn = (struct fc_ns_gid_ft *)(reqh + 1);
++ struct scatterlist *resp_entry = ct_els->resp;
++ struct fc_gpn_ft_resp *acc;
++ int max_entries, x, last = 0;
++
++ if (!(memcmp(tag, "fsscth2", 7) == 0
++ && ct_els->d_id == FC_FID_DIR_SERV
++ && reqh->ct_rev == FC_CT_REV
++ && reqh->ct_in_id[0] == 0
++ && reqh->ct_in_id[1] == 0
++ && reqh->ct_in_id[2] == 0
++ && reqh->ct_fs_type == FC_FST_DIR
++ && reqh->ct_fs_subtype == FC_NS_SUBTYPE
++ && reqh->ct_options == 0
++ && reqh->_ct_resvd1 == 0
++ && reqh->ct_cmd == FC_NS_GPN_FT
++ /* reqh->ct_mr_size can vary so do not match but read below */
++ && reqh->_ct_resvd2 == 0
++ && reqh->ct_reason == 0
++ && reqh->ct_explan == 0
++ && reqh->ct_vendor == 0
++ && reqn->fn_resvd == 0
++ && reqn->fn_domain_id_scope == 0
++ && reqn->fn_area_id_scope == 0
++ && reqn->fn_fc4_type == FC_TYPE_FCP))
++ return len; /* not GPN_FT response so do not cap */
++
++ acc = sg_virt(resp_entry);
++ max_entries = (reqh->ct_mr_size * 4 / sizeof(struct fc_gpn_ft_resp))
++ + 1 /* zfcp_fc_scan_ports: bytes correct, entries off-by-one
++ * to account for header as 1st pseudo "entry" */;
++
++ /* the basic CT_IU preamble is the same size as one entry in the GPN_FT
++ * response, allowing us to skip special handling for it - just skip it
++ */
++ for (x = 1; x < max_entries && !last; x++) {
++ if (x % (ZFCP_FC_GPN_FT_ENT_PAGE + 1))
++ acc++;
++ else
++ acc = sg_virt(++resp_entry);
++
++ last = acc->fp_flags & FC_NS_FID_LAST;
++ }
++ len = min(len, (u16)(x * sizeof(struct fc_gpn_ft_resp)));
++ return len; /* cap after last entry */
+ }
+
+ /**
+@@ -397,9 +484,10 @@ void zfcp_dbf_san_res(char *tag, struct
+ struct zfcp_fsf_ct_els *ct_els = fsf->data;
+ u16 length;
+
+- length = (u16)(ct_els->resp->length);
+- zfcp_dbf_san(tag, dbf, sg_virt(ct_els->resp), ZFCP_DBF_SAN_RES, length,
+- fsf->req_id, ct_els->d_id);
++ length = (u16)zfcp_qdio_real_bytes(ct_els->resp);
++ zfcp_dbf_san(tag, dbf, "san_res", ct_els->resp, ZFCP_DBF_SAN_RES,
++ length, fsf->req_id, ct_els->d_id,
++ zfcp_dbf_san_res_cap_len_if_gpn_ft(tag, fsf, length));
+ }
+
+ /**
+@@ -413,11 +501,13 @@ void zfcp_dbf_san_in_els(char *tag, stru
+ struct fsf_status_read_buffer *srb =
+ (struct fsf_status_read_buffer *) fsf->data;
+ u16 length;
++ struct scatterlist sg;
+
+ length = (u16)(srb->length -
+ offsetof(struct fsf_status_read_buffer, payload));
+- zfcp_dbf_san(tag, dbf, srb->payload.data, ZFCP_DBF_SAN_ELS, length,
+- fsf->req_id, ntoh24(srb->d_id));
++ sg_init_one(&sg, srb->payload.data, length);
++ zfcp_dbf_san(tag, dbf, "san_els", &sg, ZFCP_DBF_SAN_ELS, length,
++ fsf->req_id, ntoh24(srb->d_id), length);
+ }
+
+ /**
+--- a/drivers/s390/scsi/zfcp_dbf.h
++++ b/drivers/s390/scsi/zfcp_dbf.h
+@@ -115,6 +115,7 @@ struct zfcp_dbf_san {
+ u32 d_id;
+ #define ZFCP_DBF_SAN_MAX_PAYLOAD (FC_CT_HDR_LEN + 32)
+ char payload[ZFCP_DBF_SAN_MAX_PAYLOAD];
++ u16 pl_len;
+ } __packed;
+
+ /**
diff --git a/patches.arch/s390-sles11sp4-15-04-08-scsi-zfcp-spin_lock_irqsave-is-not-nestable.patch b/patches.arch/s390-sles11sp4-15-04-08-scsi-zfcp-spin_lock_irqsave-is-not-nestable.patch
new file mode 100644
index 0000000000..22bb510117
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-04-08-scsi-zfcp-spin_lock_irqsave-is-not-nestable.patch
@@ -0,0 +1,38 @@
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Fri, 14 Oct 2016 16:18:39 -0400
+Patch-mainline: v4.9-rc2
+Git-commit: e7cb08e894a0b876443ef8fdb0706575dc00a5d2
+References: bsc#1003677,LTC#147374
+Subject: [PATCH] scsi: zfcp: spin_lock_irqsave() is not nestable
+
+We accidentally overwrite the original saved value of "flags" so that we
+can't re-enable IRQs at the end of the function. Presumably this
+function is mostly called with IRQs disabled or it would be obvious in
+testing.
+
+Fixes: aceeffbb59bb ("zfcp: trace full payload of all SAN records (req,resp,iels)")
+Cc: <stable@vger.kernel.org> #2.6.38+
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Acked-by: John Jolly <jjolly@suse.de>
+---
+ drivers/s390/scsi/zfcp_dbf.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
+index 637cf89..5810019 100644
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -384,7 +384,7 @@ void zfcp_dbf_san(char *tag, struct zfcp_dbf *dbf,
+ /* if (len > rec_len):
+ * dump data up to cap_len ignoring small duplicate in rec->payload
+ */
+- spin_lock_irqsave(&dbf->pay_lock, flags);
++ spin_lock(&dbf->pay_lock);
+ memset(payload, 0, sizeof(*payload));
+ memcpy(payload->area, paytag, ZFCP_DBF_TAG_LEN);
+ payload->fsf_req_id = req_id;
+--
+1.8.5.2
+
diff --git a/patches.arch/s390-sles11sp4-15-05-cio-fix-accidental-interrupt-enabling-during-re.patch b/patches.arch/s390-sles11sp4-15-05-cio-fix-accidental-interrupt-enabling-during-re.patch
new file mode 100644
index 0000000000..d9a82ae695
--- /dev/null
+++ b/patches.arch/s390-sles11sp4-15-05-cio-fix-accidental-interrupt-enabling-during-re.patch
@@ -0,0 +1,139 @@
+From: Sebastian Ott <sebott@linux.vnet.ibm.com>
+Subject: s390/cio: fix accidental interrupt enabling during resume
+Patch-mainline: v4.9-rc1
+Git-commit: d53c51f26145657aa7c55fa396f93677e613548d
+References: bnc#1003677, LTC#147606
+
+Description: s390/cio: fix accidental interrupt enabling during resume
+Symptom: A warning is printed after resume from hibernate.
+Problem: Interrupts are accidentally enabled during resume from
+ hibernate leading to process a timer interrupt which
+ confuses time-keeping code that thinks it's still
+ sleeping.
+Solution: Fix accidental interrupt enabling during resume.
+Reproduction: resume from hibernate
+
+Upstream-Description:
+
+ s390/cio: fix accidental interrupt enabling during resume
+
+ Since commit 9f3d6d7 chsc_get_channel_measurement_chars is called with
+ interrupts disabled during resume from hibernate. Since this function
+ used spin_unlock_irq, interrupts have been enabled accidentally. Fix
+ this by using the irqsave variant.
+
+ Since we can't guarantee the IRQ-enablement state for all (future/
+ external) callers, change the locking in related functions to prevent
+ similar bugs in the future.
+
+ Fixes: 9f3d6d7 ("s390/cio: update measurement characteristics")
+ Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
+ Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+
+
+Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
+Acked-by: John Jolly <jjolly@suse.com>
+---
+ drivers/s390/cio/chsc.c | 20 ++++++++++++--------
+ 1 file changed, 12 insertions(+), 8 deletions(-)
+
+--- a/drivers/s390/cio/chsc.c
++++ b/drivers/s390/cio/chsc.c
+@@ -93,12 +93,13 @@ struct chsc_ssd_area {
+ int chsc_get_ssd_info(struct subchannel_id schid, struct chsc_ssd_info *ssd)
+ {
+ struct chsc_ssd_area *ssd_area;
++ unsigned long flags;
+ int ccode;
+ int ret;
+ int i;
+ int mask;
+
+- spin_lock_irq(&chsc_page_lock);
++ spin_lock_irqsave(&chsc_page_lock, flags);
+ memset(chsc_page, 0, PAGE_SIZE);
+ ssd_area = chsc_page;
+ ssd_area->request.length = 0x0010;
+@@ -142,7 +143,7 @@ int chsc_get_ssd_info(struct subchannel_
+ ssd->fla[i] = ssd_area->fla[i];
+ }
+ out:
+- spin_unlock_irq(&chsc_page_lock);
++ spin_unlock_irqrestore(&chsc_page_lock, flags);
+ return ret;
+ }
+
+@@ -665,9 +666,10 @@ int __chsc_do_secm(struct channel_subsys
+ u32 fmt : 4;
+ u32 : 16;
+ } __attribute__ ((packed)) *secm_area;
++ unsigned long flags;
+ int ret, ccode;
+
+- spin_lock_irq(&chsc_page_lock);
++ spin_lock_irqsave(&chsc_page_lock, flags);
+ memset(chsc_page, 0, PAGE_SIZE);
+ secm_area = chsc_page;
+ secm_area->request.length = 0x0050;
+@@ -697,7 +699,7 @@ int __chsc_do_secm(struct channel_subsys
+ CIO_CRW_EVENT(2, "chsc: secm failed (rc=%04x)\n",
+ secm_area->response.code);
+ out:
+- spin_unlock_irq(&chsc_page_lock);
++ spin_unlock_irqrestore(&chsc_page_lock, flags);
+ return ret;
+ }
+
+@@ -826,6 +828,7 @@ chsc_initialize_cmg_chars(struct channel
+
+ int chsc_get_channel_measurement_chars(struct channel_path *chp)
+ {
++ unsigned long flags;
+ int ccode, ret;
+
+ struct {
+@@ -855,7 +858,7 @@ int chsc_get_channel_measurement_chars(s
+ if (!css_chsc_characteristics.scmc || !css_chsc_characteristics.secm)
+ return 0;
+
+- spin_lock_irq(&chsc_page_lock);
++ spin_lock_irqsave(&chsc_page_lock, flags);
+ memset(chsc_page, 0, PAGE_SIZE);
+ scmc_area = chsc_page;
+ scmc_area->request.length = 0x0010;
+@@ -887,7 +890,7 @@ int chsc_get_channel_measurement_chars(s
+ chsc_initialize_cmg_chars(chp, scmc_area->cmcv,
+ (struct cmg_chars *) &scmc_area->data);
+ out:
+- spin_unlock_irq(&chsc_page_lock);
++ spin_unlock_irqrestore(&chsc_page_lock, flags);
+ return ret;
+ }
+
+@@ -971,6 +974,7 @@ struct css_chsc_char css_chsc_characteri
+ int __init
+ chsc_determine_css_characteristics(void)
+ {
++ unsigned long flags;
+ int result;
+ struct {
+ struct chsc_header request;
+@@ -983,7 +987,7 @@ chsc_determine_css_characteristics(void)
+ u32 chsc_char[508];
+ } __attribute__ ((packed)) *scsc_area;
+
+- spin_lock_irq(&chsc_page_lock);
++ spin_lock_irqsave(&chsc_page_lock, flags);
+ memset(chsc_page, 0, PAGE_SIZE);
+ scsc_area = chsc_page;
+ scsc_area->request.length = 0x0010;
+@@ -1005,7 +1009,7 @@ chsc_determine_css_characteristics(void)
+ CIO_CRW_EVENT(2, "chsc: scsc failed (rc=%04x)\n",
+ scsc_area->response.code);
+ exit:
+- spin_unlock_irq(&chsc_page_lock);
++ spin_unlock_irqrestore(&chsc_page_lock, flags);
+ return result;
+ }
+
diff --git a/series.conf b/series.conf
index 31ce5f3138..93ccf51746 100644
--- a/series.conf
+++ b/series.conf
@@ -1550,6 +1550,20 @@
patches.arch/s390-sles11sp4-14-01-dasd-fix-hanging-device-after-clear-subchannel.patch
+ patches.arch/s390-sles11sp4-15-01-01-move-ptff.patch
+ patches.arch/s390-sles11sp4-15-01-02-lpar-offset.patch
+ patches.arch/s390-sles11sp4-15-02-zfcp-fix-ELS-GS-request-response-length-for-hardware.patch
+ patches.arch/s390-sles11sp4-15-03-zfcp-close-window-with-unblocked-rport-during-rport-.patch
+ patches.arch/s390-sles11sp4-15-04-01-zfcp-retain-trace-level-for-SCSI-and-HBA-FSF-respons.patch
+ patches.arch/s390-sles11sp4-15-04-02-zfcp-restore-Dont-use-0-to-indicate-invalid-LUN-in-r.patch
+ patches.arch/s390-sles11sp4-15-04-03-zfcp-trace-on-request-for-open-and-close-of-WKA-port.patch
+ patches.arch/s390-sles11sp4-15-04-04-zfcp-restore-tracing-of-handle-for-port-and-LUN-with.patch
+ patches.arch/s390-sles11sp4-15-04-05-zfcp-fix-D_ID-field-with-actual-value-on-tracing-SAN.patch
+ patches.arch/s390-sles11sp4-15-04-06-zfcp-fix-payload-trace-length-for-SAN-request-respon.patch
+ patches.arch/s390-sles11sp4-15-04-07-zfcp-trace-full-payload-of-all-SAN-records-req-resp-.patch
+ patches.arch/s390-sles11sp4-15-04-08-scsi-zfcp-spin_lock_irqsave-is-not-nestable.patch
+ patches.arch/s390-sles11sp4-15-05-cio-fix-accidental-interrupt-enabling-during-re.patch
+
########################################################
# VM/FS patches
########################################################