linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Akinobu Mita <akinobu.mita@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <kbusch@kernel.org>,
	Keith Busch <keith.busch@intel.com>,
	linux-nvme@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	Johannes Berg <johannes@sipsolutions.net>,
	Jens Axboe <axboe@fb.com>, Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH 0/4] nvme-pci: support device coredump
Date: Sat, 4 May 2019 13:20:50 +0900	[thread overview]
Message-ID: <CAC5umyiGbDNCtzhJioR_2EV6-6xMuZXOMThCizwJEMHi+KqxAw@mail.gmail.com> (raw)
In-Reply-To: <20190503122035.GA21501@lst.de>

2019年5月3日(金) 21:20 Christoph Hellwig <hch@lst.de>:
>
> On Fri, May 03, 2019 at 06:12:32AM -0600, Keith Busch wrote:
> > 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.

I agree that the device specific internal logs like telemetry are the most
useful.  The memory dump of command queues and completion queues is not
that powerful but helps to know what commands have been submitted before
the controller goes wrong (IOW, it's sometimes not enough to know
which commands are actually failed), and it can be parsed without vendor
specific knowledge.

If the issue is reproducible, the nvme trace is the most powerful for this
kind of information.  The memory dump of the queues is not that powerful,
but it can always be enabled by default.

> Yes.  Also not that NVMe now has the 'device initiated telemetry'
> feauture, which is just a wired name for device coredump.  Wiring that
> up so that we can easily provide that data to the device vendor would
> actually be pretty useful.

This version of nvme coredump captures controller registers and each queue.
So before resetting controller is a suitable time to capture these.
If we'll capture other log pages in this mechanism, the coredump procedure
will be splitted into two phases (before resetting controller and after
resetting as soon as admin queue is available).

  reply	other threads:[~2019-05-04  4:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-02  8:59 [PATCH 0/4] nvme-pci: support device coredump Akinobu Mita
2019-05-02  8:59 ` [PATCH 1/4] devcoredump: use memory_read_from_buffer Akinobu Mita
2019-05-02 12:42   ` Johannes Berg
2019-05-02  8:59 ` [PATCH 2/4] devcoredump: allow to create several coredump files in one device Akinobu Mita
2019-05-02 12:47   ` Johannes Berg
2019-05-03  3:41     ` Akinobu Mita
2019-05-02  8:59 ` [PATCH 3/4] nvme-pci: add device coredump support Akinobu Mita
2019-05-04 10:04   ` Minwoo Im
2019-05-04 14:26     ` Akinobu Mita
2019-05-04 14:38       ` Minwoo Im
2019-05-04 14:46         ` Minwoo Im
2019-05-02  8:59 ` [PATCH 4/4] nvme-pci: trigger device coredump before resetting controller Akinobu Mita
2019-05-02 12:57 ` [PATCH 0/4] nvme-pci: support device coredump Keith Busch
2019-05-03  3:38   ` Akinobu Mita
2019-05-03 12:12     ` Keith Busch
2019-05-03 12:20       ` Christoph Hellwig
2019-05-04  4:20         ` Akinobu Mita [this message]
2019-05-04  9:40           ` Minwoo Im
2019-05-04 14:36             ` Akinobu Mita

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=CAC5umyiGbDNCtzhJioR_2EV6-6xMuZXOMThCizwJEMHi+KqxAw@mail.gmail.com \
    --to=akinobu.mita@gmail.com \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=johannes@sipsolutions.net \
    --cc=kbusch@kernel.org \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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).