From patchwork Wed Jul 25 19:55:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: James Bottomley X-Patchwork-Id: 173252 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 027BC2C00A5 for ; Thu, 26 Jul 2012 05:56:14 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752447Ab2GYT4H (ORCPT ); Wed, 25 Jul 2012 15:56:07 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:47877 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752432Ab2GYT4D (ORCPT ); Wed, 25 Jul 2012 15:56:03 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id D6AAB8EE144; Wed, 25 Jul 2012 12:56:01 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0sIQ7m5-Z6B; Wed, 25 Jul 2012 12:56:01 -0700 (PDT) Received: from [10.0.0.170] (unknown [194.186.187.194]) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 611458EE092; Wed, 25 Jul 2012 12:55:58 -0700 (PDT) Message-ID: <1343246155.12094.59.camel@dabdike> Subject: Re: 'Device not ready' issue on mpt2sas since 3.1.10 From: James Bottomley To: Tejun Heo Cc: Matthias Prager , Robert Trace , linux-scsi@vger.kernel.org, Jens Axboe , Eric Moore , Alan , "Darrick J. Wong" , linux-ide@vger.kernel.org Date: Wed, 25 Jul 2012 23:55:55 +0400 In-Reply-To: <20120725171723.GB32378@google.com> References: <4FFB8A86.7000009@farcaster.org> <4FFCBA4C.4000502@farcaster.org> <4FFD6F3D.2030708@matthiasprager.de> <4FFD8410.7050604@matthiasprager.de> <20120717180932.GB2878@google.com> <5005BF7D.2050703@matthiasprager.de> <20120717200136.GC24336@google.com> <500A9D7C.8080801@matthiasprager.de> <20120722173146.GE5144@dhcp-172-17-108-109.mtv.corp.google.com> <1343225953.12094.55.camel@dabdike> <20120725171723.GB32378@google.com> X-Mailer: Evolution 3.2.3 Mime-Version: 1.0 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org On Wed, 2012-07-25 at 10:17 -0700, Tejun Heo wrote: > Hello, James. > > On Wed, Jul 25, 2012 at 06:19:13PM +0400, James Bottomley wrote: > > > I haven't consulted SAT but it seems like a bug in SAS driver or > > > firmware. If it's a driver bug, we better fix it there. If a > > > firmware bug, working around those is one of major roles of drivers, > > > so I think setting allow_restart is fine. > > > > Actually, I don't think so. SAT-2 section 8.12.2 does say > > > > if the device is in the stopped state as the result of > > processing a START STOP UNIT command (see 9.11), then the SATL > > shall terminate the TEST UNIT READY command with CHECK CONDITION > > status with the sense key set to NOT READY and the additional > > sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND > > REQUIRED; > > > > START STOP UNIT (with START=0) translates to STANDBY IMMEDIATE, and > > that's what hdparm -y issues. We don't see this in /drivers/ata because > > TEST UNIT READY always returns success. > > Urgh... ATA device in standby mode is ready for any command and > definitely doesn't need an "initializing command". Oh, well... Well, it does in sleep mode ... which seems to most closely map to what SCSI thinks of as a stopped unit. I checked the specs just in case there was an error ... they all say STANDBY not SLEEP. > > So it looks like the mpt2sas SAT is doing the correct thing and we only > > don't see this problem in normal SATA devices because of a bug in the > > libata-scsi SAT. > > libata is inconsistent with the standard but I think the standard is > wrong here. :( Well, reading it, so do I. Unfortunately, we get to deal with the world as it is rather than as we would wish it to be. We likely have this problem with a lot of USB SATLs as well ... It looks like a hack like this might be needed. James --- -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 4a6381c..7e59a7f 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -42,6 +42,8 @@ #include +static void scsi_eh_done(struct scsi_cmnd *scmd); + #define SENSE_TIMEOUT (10*HZ) /* @@ -241,6 +243,14 @@ static int scsi_check_sense(struct scsi_cmnd *scmd) if (! scsi_command_normalize_sense(scmd, &sshdr)) return FAILED; /* no valid sense data */ + if (scmd->cmnd[0] == TEST_UNIT_READY && scmd->scsi_done != scsi_eh_done) + /* + * nasty: for mid-layer issued TURs, we need to return the + * actual sense data without any recovery attempt. For eh + * issued ones, we need to try to recover and interpret + */ + return SUCCESS; + if (scsi_sense_is_deferred(&sshdr)) return NEEDS_RETRY; diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 56a9379..91d3366 100644 --- a/drivers/scsi/scsi_scan.c +++ b/drivers/scsi/scsi_scan.c @@ -764,6 +764,16 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned char *inq_result, sdev->model = (char *) (sdev->inquiry + 16); sdev->rev = (char *) (sdev->inquiry + 32); + if (strncmp(sdev->vendor, "ATA ", 8) == 0) { + /* + * sata emulation layer device. This is a hack to work around + * the SATL power management specifications which state that + * when the SATL detects the device has gone into standby + * mode, it shall respond with NOT READY. + */ + sdev->allow_restart = 1; + } + if (*bflags & BLIST_ISROM) { sdev->type = TYPE_ROM; sdev->removable = 1;