Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp465108yba; Fri, 3 May 2019 05:20:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqyAY81aei0IamyuJBtpjB/SBSGLHCFIOyKIunOR8qI+GaV9uNcQRW7Z57jaTYqs4ngwrsMA X-Received: by 2002:a17:902:b948:: with SMTP id h8mr9849671pls.39.1556886043437; Fri, 03 May 2019 05:20:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556886043; cv=none; d=google.com; s=arc-20160816; b=jFOCj7bk3LtRHVkKDzafmTy8bMDuw7Na7fCAFygYMv/A7OUsblCwpAT0+PiDp7F/MD zRI/njoKI9J6MhBDkj2RupIUAikkhVq49faE3/F2hAVsYo0bIBicDypQf0eQ+G0PFoPR FLGpwhXg/cOrdEnnAegBffc3xJl2GAfMDrP2nwUETF1+JV5mudrfTIGgAPBYfJCDv+9O vz7SqN3zxxdRfIMJkU8T5L8Kg5Rl021n/yZqdTJlgTz3MC9/G3TelhjlAhIKOu6Axdza 1dY9SHtkm7ROqsBigLregeWYFr6e5DQAn9md6JXjcATr30Pnxr5JUtRwpU82elnrjnlb DQcA== 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; bh=vLCh0LilSi5799pNnCtfDo8ngyBhVuTVsKPEWaxGk30=; b=PG19ehI92SLj3/pJ77pHYpKjSd+2dJ80E5l7uRQQPLUCcE8nxToM5xFagmELaDlEC4 mVetUIdcrv8X76gGnwH49sDGNFu/wcQ25jG9BTLwDdH85sOcrXuKOZhx46ME3lAqjnbC bysb6Ved41X/eEPbdg6NvLYIWFNlE0eSZv3bNHQ00760z+vI2qTfsC4IvW0N3AIZ6SS8 jtcx8vAJ5sxOmNcmfIJgUp4QLbRJXvGgfxgrSP/AHU01JNHLIYyo2i3NJlzY8UOyGSHO IBgDP2Ib8zUFrXmhzyP/EGO48PSmh58oTf9EfNiHhJyrfs/w9T1GACf1eYCpl+0eAhTS +CWw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q10si2104856pll.40.2019.05.03.05.20.27; Fri, 03 May 2019 05:20:43 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727523AbfECMSQ (ORCPT + 99 others); Fri, 3 May 2019 08:18:16 -0400 Received: from mga04.intel.com ([192.55.52.120]:42015 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726289AbfECMSP (ORCPT ); Fri, 3 May 2019 08:18:15 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2019 05:18:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,425,1549958400"; d="scan'208";a="167227563" Received: from unknown (HELO localhost.localdomain) ([10.232.112.69]) by fmsmga002.fm.intel.com with ESMTP; 03 May 2019 05:18:14 -0700 Date: Fri, 3 May 2019 06:12:32 -0600 From: Keith Busch To: Akinobu Mita Cc: Keith Busch , linux-nvme@lists.infradead.org, LKML , Johannes Berg , Jens Axboe , Christoph Hellwig , Sagi Grimberg Subject: Re: [PATCH 0/4] nvme-pci: support device coredump Message-ID: <20190503121232.GB30013@localhost.localdomain> References: <1556787561-5113-1-git-send-email-akinobu.mita@gmail.com> <20190502125722.GA28470@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 Fri, May 03, 2019 at 12:38:08PM +0900, Akinobu Mita wrote: > 2019年5月2日(木) 22:03 Keith Busch : > > On Thu, May 02, 2019 at 05:59:17PM +0900, Akinobu Mita wrote: > > > This enables to capture snapshot of controller information via device > > > coredump machanism, and it helps diagnose and debug issues. > > > > > > The nvme device coredump is triggered before resetting the controller > > > caused by I/O timeout, and creates the following coredump files. > > > > > > - regs: NVMe controller registers, including each I/O queue doorbell > > > registers, in nvme-show-regs style text format. > > > > You're supposed to treat queue doorbells as write-only. Spec says: > > > > The host should not read the doorbell registers. If a doorbell register > > is read, the value returned is vendor specific. > > OK. I'll exclude the doorbell registers from register dump. It will work > out without the information if we have snapshot of the queues. Could you actually explain how the rest is useful? I personally have never encountered an issue where knowing these values would have helped: every device timeout always needed device specific internal firmware logs in my experience.