Received: by 10.223.176.46 with SMTP id f43csp1329122wra; Wed, 24 Jan 2018 14:44:21 -0800 (PST) X-Google-Smtp-Source: AH8x226KfiZYJznAwh1SwKDLqouLhQU/MtfZ3GSuxRaX3TQ66VhiGW1kYKh756Kh0/qilg60DWOI X-Received: by 2002:a17:902:622:: with SMTP id 31-v6mr9328826plg.448.1516833861158; Wed, 24 Jan 2018 14:44:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516833861; cv=none; d=google.com; s=arc-20160816; b=qJXikqTZuen5ovO0mRc3aQ0CoBavg0zmrM8NhsqNFQEH/VaDmzIqWci/N9OUjy5iw5 36ev/4spQ/ztJIy8MoBfNP681zoOeaNXUpX6ZhH+YWR8O5mCV0OCnLBJdUcUoQ4SClUe t7DqzWufUYRtgaWoAjSOAb1c1ChhBuVHAWYRYy3at/eAZJlvHBz68Woa5TGsKyr1uGaJ M1y31B9oRrsTbrUrh2BXXiBVjWGDz98zvybmtNcEjyglgWZ5sbLdF6apT5vaG24GSPUs 6FOvnMMVl+F1RaMAs+whPRYITsp9av8kSrPZgg4v7nr0+xxIJfXJiaqRkif5hwwwH1DA aRiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=AFC4Z1LRI17MKZLQTpyCe/il4mOceuj327B03tElDAo=; b=B8g43zFCPffNGPSc2KGjhZHpAFz3O9DWAXqP30NxCwvofEI0EuE/LTgF7GsvKgFu1O ZBqjhT8AMwG8pyQVBqReF1Kl1yqmSY4jZvlSxYijKNsQKptaVwG+O1+VS8fg6wCaK9bU Oizm6W3RMuk+9vaNvsU8swk4rSBRlylPWnB6mszwHlPVcj+jD5b25S/w2X3JR3gazDL/ hy3ytSdVbAHap3gQG0Jj68frTcMw/7Bk8NJRQiIP+lDDNOAZ/bJ3F5xJZZjB/Kh2RxRW nCNwry6is6/jZRVyY6PiaxUGibLXjJwEpFPblwHxxZl5/eyvd8WfGdL43k5WOX+IuhLN DYHQ== 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 f91-v6si844851plb.377.2018.01.24.14.44.06; Wed, 24 Jan 2018 14:44:21 -0800 (PST) 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 S932880AbeAXWnm (ORCPT + 99 others); Wed, 24 Jan 2018 17:43:42 -0500 Received: from mga01.intel.com ([192.55.52.88]:53913 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932072AbeAXWnl (ORCPT ); Wed, 24 Jan 2018 17:43:41 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 14:43:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,409,1511856000"; d="scan'208";a="12933499" Received: from unknown (HELO localhost.localdomain) ([10.232.112.44]) by fmsmga008.fm.intel.com with ESMTP; 24 Jan 2018 14:43:41 -0800 Date: Wed, 24 Jan 2018 15:47:12 -0700 From: Keith Busch To: Paul Menzel Cc: Jens Axboe , Christoph Hellwig , Sagi Grimberg , linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: Report long suspend times of NVMe devices (mostly firmware/device issues) Message-ID: <20180124224711.GF14790@localhost.localdomain> References: <9e398971-762d-bb1a-f798-bf0b18cb5b6b@molgen.mpg.de> <20180122213024.GR12043@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 24, 2018 at 11:29:12PM +0100, Paul Menzel wrote: > Am 22.01.2018 um 22:30 schrieb Keith Busch: > > The nvme spec guides toward longer times than that. I don't see the > > point of warning users about things operating within spec. > > I quickly glanced over NVM Express revision 1.3 specification [1] but > searching for *second *, I could not find something about this. Could you > please point me to the section? Section 7.6.2: It is recommended that the host wait a minimum of the RTD3 Entry Latency reported in the Identify Controller data structure for the shutdown operations to complete; if the value reported in RTD3 Entry Latency is 0h, then the host should wait for a minimum of one second. So if the controller is new enough, it will report it's RTD3 Entry. The maximum allowed by spec is something like 4000 seconds. For controllers that pre-date this field, we're supposed to wait a "minimum" of one second. The spec does not recommend a maximum time in either case. > In my opinion, it’s a good thing to point users to devices holding up > suspend. If a device shutdown exceeds its reported constraints, then absolutely, and we do log a warning for that already. Picking an arbitrary time below spec recommendations is just guaranteed to create alarmed people demanding answers to a warning about behavior that is entirely normal.