All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Adamson <alan.adamson@oracle.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"axboe@fb.com" <axboe@fb.com>,
	"sagi@grimberg.me" <sagi@grimberg.me>
Subject: Re: [PATCH 0/1] nvme: Export CSTS register via sysfs
Date: Wed, 5 May 2021 20:23:43 +0000	[thread overview]
Message-ID: <07E6C0A9-D180-4A4E-A10E-2423094E71B2@oracle.com> (raw)
In-Reply-To: <20210505201114.GA1186772@dhcp-10-100-145-180.wdc.com>



> On May 5, 2021, at 1:11 PM, Keith Busch <kbusch@kernel.org> wrote:
> 
> On Wed, May 05, 2021 at 06:40:54PM +0000, Alan Adamson wrote:
>> Need to revisit this issue again.  In the original case we needed to
>> get access to the csts register. We were able to move to using the
>> ’state’ sysfs attribute.
>> 
>> We are now getting a similar request from our manufacturing team. They
>> are using nvme-cli show-regs to assist debug. The ’state’ attribute is
>> not sufficient and they want to use the production version of the
>> kernel (which enables CONFIG_IO_STRICT_DEVMEM) rather than a special
>> kernel. Ideally, we would want nvme-cli show-regs to work whether or
>> not CONFIG_IO_STRICT_DEVMEM is configured. Other than exporting the
>> registers thru sysfs attributes, is there any other mechanism to get
>> show-regs the data it needs?
> 
> Append kernel parameter "iomem=relaxed”.

That requires the OS disk to be modified.  We would rather not do that.

Alan



_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2021-05-05 20:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 20:46 [PATCH 0/1] nvme: Export CSTS register via sysfs Alan Adamson
2021-03-17 20:46 ` [PATCH 1/1] " Alan Adamson
2021-03-18  1:06 ` [PATCH 0/1] " Chaitanya Kulkarni
2021-03-18  4:38 ` Christoph Hellwig
2021-03-18 14:19   ` Keith Busch
2021-03-18 16:28   ` Alan Adamson
2021-03-18 16:52     ` Keith Busch
2021-03-18 18:39       ` Alan Adamson
2021-03-18 19:46         ` Keith Busch
2021-03-19  6:51           ` Christoph Hellwig
2021-03-19 15:22             ` Keith Busch
2021-03-19 15:30               ` Christoph Hellwig
2021-03-19 17:21                 ` Alan Adamson
2021-03-19 17:30                   ` Keith Busch
2021-03-19 17:33                     ` Alan Adamson
2021-05-05 18:40                     ` Alan Adamson
2021-05-05 20:11                       ` Keith Busch
2021-05-05 20:23                         ` Alan Adamson [this message]
2021-05-05 20:35                           ` Keith Busch
2021-03-18 19:15       ` Chaitanya Kulkarni

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=07E6C0A9-D180-4A4E-A10E-2423094E71B2@oracle.com \
    --to=alan.adamson@oracle.com \
    --cc=axboe@fb.com \
    --cc=hch@lst.de \
    --cc=kbusch@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.