linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Steffen Maier <maier@linux.vnet.ibm.com>,
	"James E . J . Bottomley" <jejb@linux.vnet.ibm.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org, linux-s390@vger.kernel.org,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	"# 3 . 2+" <stable@vger.kernel.org>
Subject: Re: [PATCH 02/10] zfcp: fix ELS/GS request&response length for hardware data router
Date: Thu, 11 Aug 2016 13:20:23 +0200	[thread overview]
Message-ID: <486ac2fb-b54c-f007-603c-ad0b7f099b09@suse.de> (raw)
In-Reply-To: <1470846653-90691-3-git-send-email-maier@linux.vnet.ibm.com>

On 08/10/2016 06:30 PM, Steffen Maier wrote:
> 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>
> ---
>  drivers/s390/scsi/zfcp_fsf.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
Reviewed-by: Hannes Reinecke <hare@suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

  reply	other threads:[~2016-08-11 11:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-10 16:30 [PATCH 00/10] zfcp fixes Steffen Maier
2016-08-10 16:30 ` [PATCH 01/10] zfcp: fix fc_host port_type with NPIV Steffen Maier
2016-08-11 11:19   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 02/10] zfcp: fix ELS/GS request&response length for hardware data router Steffen Maier
2016-08-11 11:20   ` Hannes Reinecke [this message]
2016-08-10 16:30 ` [PATCH 03/10] zfcp: close window with unblocked rport during rport gone Steffen Maier
2016-08-11 11:21   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 04/10] zfcp: retain trace level for SCSI and HBA FSF response records Steffen Maier
2016-08-11 11:21   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 05/10] zfcp: restore: Dont use 0 to indicate invalid LUN in rec trace Steffen Maier
2016-08-11 11:22   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 06/10] zfcp: trace on request for open and close of WKA port Steffen Maier
2016-08-11 11:22   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 07/10] zfcp: restore tracing of handle for port and LUN with HBA records Steffen Maier
2016-08-11 11:23   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 08/10] zfcp: fix D_ID field with actual value on tracing SAN responses Steffen Maier
2016-08-11 11:24   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 09/10] zfcp: fix payload trace length for SAN request&response Steffen Maier
2016-08-11 11:24   ` Hannes Reinecke
2016-08-10 16:30 ` [PATCH 10/10] zfcp: trace full payload of all SAN records (req,resp,iels) Steffen Maier
2016-08-11 11:25   ` Hannes Reinecke
2016-08-12 20:18 ` [PATCH 00/10] zfcp fixes Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=486ac2fb-b54c-f007-603c-ad0b7f099b09@suse.de \
    --to=hare@suse.de \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=maier@linux.vnet.ibm.com \
    --cc=martin.petersen@oracle.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).