Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp1776027ybi; Sat, 8 Jun 2019 18:31:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEf4y6408EZ7SbB3/xX1nt2hMH8ixh72e0AQQUiriN20YTtjbdDKvQuNt5e8P8Zs2O6fWF X-Received: by 2002:aa7:8292:: with SMTP id s18mr36704296pfm.111.1560043868424; Sat, 08 Jun 2019 18:31:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560043868; cv=none; d=google.com; s=arc-20160816; b=b/k7G27t7obmrCNmzdSKJF70epBYm5/qltaSpDil21xjdROrh1emQ/oYwh9nO2lUXi rFSCW8FqPd9+rSoeNQWS/Z4G0IsWZpkJ9VyExepgmKPG6o1wQkEb1AwZ2xpA/h31VM4R 0eDGwhfS93BwSQh82ZV6l/dC7gCqTN5tBG8tIlXgdjcBdLnXYPaQKtM4w/AhfRpWxSCk ut/L9X+z60h23fGb+cTXf+PQgdfbziQeOArEmiq7owM6bbiKwXkdsL5S6SOJvmTTE4h/ iA+1wxY3+PuDktGMubAdoieDLRIrhnGy+n9JkP7zzOogBDW+ui989QImawmIbhDLYlMb DhRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:from:references:in-reply-to :message-id:cc:to; bh=2Y2rZLo4xB8Zo8WSdfegfDM9plQ4y/slKpQwsz/PLUg=; b=YivfvOFf8LVtsLh8djHDCL7OwRKcENNY9n0eBFa7JGUluXYvjiNKOpWDsskoRVzOo0 km2lzlkTWNOmfhTwgPMZUfJuSkthHtLt4LoNkceLHPrATIvHyO2j4N/tGeyCFiOApHhy UJ4rc7/b36eg72o0z/sAIAbsIg11PYscBuYSk0ZvnhqrwjVJ1Y/PY4vLQQnKBazR94n5 zdpou3xgRrHHk7M9qK7BNKgzL/BnHE1KbV0M2bf2YVA2ExcFb3gkMgKpeW9ZYnHaAcmC KvSlB9zCBjm/DzUFWGGmt0KSs3e35mliUgS8qtPESJx+WuksKVHtrcc80nWBFqyzwKhD TQxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o4si5851029pgp.476.2019.06.08.18.30.19; Sat, 08 Jun 2019 18:31:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727981AbfFIB0p (ORCPT + 99 others); Sat, 8 Jun 2019 21:26:45 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:59968 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727703AbfFIB0o (ORCPT ); Sat, 8 Jun 2019 21:26:44 -0400 Received: by kvm5.telegraphics.com.au (Postfix, from userid 502) id D3B5327AF4; Sat, 8 Jun 2019 21:26:42 -0400 (EDT) To: "James E.J. Bottomley" , "Martin K. Petersen" Cc: "Michael Schmitz" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Message-Id: <4f1de194d0d8fdca36f0f7e90ced7bc5fe1f78f6.1560043151.git.fthain@telegraphics.com.au> In-Reply-To: References: From: Finn Thain Subject: [PATCH v2 4/7] scsi: mac_scsi: Increase PIO/PDMA transfer length threshold Date: Sun, 09 Jun 2019 11:19:11 +1000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Some targets introduce delays when handshaking the response to certain commands. For example, a disk may send a 96-byte response to an INQUIRY command (or a 24-byte response to a MODE SENSE command) too slowly. Apparently the first 12 or 14 bytes are handshaked okay but then the system bus error timeout is reached while transferring the next word. Since the scsi bus phase hasn't changed, the driver then sets the target borken flag to prevent further PDMA transfers. The driver also logs the warning, "switching to slow handshake". Raise the PDMA threshold to 512 bytes so that PIO transfers will be used for these commands. This default is sufficiently low that PDMA will still be used for READ and WRITE commands. The existing threshold (16 bytes) was chosen more or less at random. However, best performance requires the threshold to be as low as possible. Those systems that don't need the PIO workaround at all may benefit from mac_scsi.setup_use_pdma=1 Cc: Michael Schmitz Cc: stable@vger.kernel.org # v4.14+ Fixes: 3a0f64bfa907 ("mac_scsi: Fix pseudo DMA implementation") Tested-by: Stan Johnson Signed-off-by: Finn Thain --- drivers/scsi/mac_scsi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/mac_scsi.c b/drivers/scsi/mac_scsi.c index 8b4b5b1a13d7..ba1afcaadae8 100644 --- a/drivers/scsi/mac_scsi.c +++ b/drivers/scsi/mac_scsi.c @@ -52,7 +52,7 @@ static int setup_cmd_per_lun = -1; module_param(setup_cmd_per_lun, int, 0); static int setup_sg_tablesize = -1; module_param(setup_sg_tablesize, int, 0); -static int setup_use_pdma = -1; +static int setup_use_pdma = 512; module_param(setup_use_pdma, int, 0); static int setup_hostid = -1; module_param(setup_hostid, int, 0); @@ -305,7 +305,7 @@ static int macscsi_dma_xfer_len(struct NCR5380_hostdata *hostdata, struct scsi_cmnd *cmd) { if (hostdata->flags & FLAG_NO_PSEUDO_DMA || - cmd->SCp.this_residual < 16) + cmd->SCp.this_residual < setup_use_pdma) return 0; return cmd->SCp.this_residual; -- 2.21.0