11:25 p.m.
Hi,
In online FW upgrade process, the memblaze Pblaze4 NVMe device requires an
extra delay during controller reset process. The following patch email from
HGST describes the similar issue in detail.
*Subject: [PATCH v3] nvme/quirk: Add a delay before checking for adapter
readiness*
*When disabling the controller, the specification says the register
NVME_REG_CC should be written and then driver needs to wait the adapter to
be ready, which is checked by reading another register bit (NVME_CSTS_RDY).
There's a timeout validation in this checking, so in case this timeout is
reached the driver gives up and removes the adapter from the system.*
*After a firmware activation procedure, the PCI_DEVICE(0x1c58, 0x0003)
(HGST adapter) end up being removed if we issue a reset_controller, because
driver keeps verifying the NVME_REG_CSTS until the timeout is reached. This
patch adds a necessary quirk for this adapter, by introducing a delay
before nvme_wait_ready(), so the reset procedure is able to be completed.
This quirk is needed because just increasing the timeout is not enough in
case of this adapter - the driver must wait before start reading
NVME_REG_CSTS register on this specific device.*
The standard Linux NVMe driver now has quirk
“NVME_QUIRK_DELAY_BEFORE_CHK_RDY” for HGST and memblaze devices. Is there
any plan to add this to SPDK?
Thanks,
-Wenbo
11:03 a.m.
Currently we have no mechanism for adding device-specific quirks to the SPDK NVMe driver.
We'd certainly consider adding quirks in the same fashion as the Linux kernel driver
though, and would welcome patches that improved the applicability of SPDK to a wider range
of (potentially out of spec) devices. I'm sure over time the team at Intel working on
SPDK will add this, but it is not on our immediate roadmap, so patches from the community
would be the best way to get this going.
Thanks,
Ben
On Thu, 2016-09-08 at 14:25 +0800, Wang Weber wrote:
Hi,
In online FW upgrade process, the memblaze Pblaze4 NVMe device requires an extra delay
during controller reset process. The following patch email from HGST describes the similar
issue in detail.
Subject: [PATCH v3] nvme/quirk: Add a delay before checking for adapter readiness
When disabling the controller, the specification says the register NVME_REG_CC should be
written and then driver needs to wait the adapter to be ready, which is checked by reading
another register bit (NVME_CSTS_RDY). There's a timeout validation in this checking,
so in case this timeout is reached the driver gives up and removes the adapter from the
system.
After a firmware activation procedure, the PCI_DEVICE(0x1c58, 0x0003) (HGST adapter) end
up being removed if we issue a reset_controller, because driver keeps verifying the
NVME_REG_CSTS until the timeout is reached. This patch adds a necessary quirk for this
adapter, by introducing a delay before nvme_wait_ready(), so the reset procedure is able
to be completed. This quirk is needed because just increasing the timeout is not enough in
case of this adapter - the driver must wait before start reading NVME_REG_CSTS register on
this specific device.
The standard Linux NVMe driver now has quirk “NVME_QUIRK_DELAY_BEFORE_CHK_RDY” for HGST
and memblaze devices. Is there any plan to add this to SPDK?
Thanks,
-Wenbo
_______________________________________________
SPDK mailing list
SPDK@lists.01.org<mailto:SPDK@lists.01.org>
https://lists.01.org/mailman/listinfo/spdk
9:20 a.m.
On 09/09/2016 11:03 AM, Walker, Benjamin wrote:
Currently we have no mechanism for adding device-specific quirks to
the
SPDK NVMe driver. We'd certainly consider adding quirks in the same
fashion as the Linux kernel driver though, and would welcome patches
that improved the applicability of SPDK to a wider range of (potentially
out of spec) devices. I'm sure over time the team at Intel working on
SPDK will add this, but it is not on our immediate roadmap, so patches
from the community would be the best way to get this going.
Thanks,
Ben
The SPDK NVMe driver does have a quirk system that is currently used
only for Intel-specific quirks (see lib/nvme/nvme_intel.c); however, the
structure used just matches against a PCI device ID in a generic way, so
we should be able to extend this for use with other devices.
I think the ideal first patch to add such a quirk would be to rename the
nvme_intel file and structures to be generic. Then we could add new
quirk flags to describe whatever non-spec-compliant behavior is required
to make these devices work.
Thanks,
-- Daniel
7:16 p.m.
Thanks for the information.
Is there a plan to update nvme_intel.c to be geneirc? or may I modify
it and upload the patch to the community? Thanks.
2016-09-13 0:20 GMT+08:00 Daniel Verkamp <daniel.verkamp(a)intel.com>:
On 09/09/2016 11:03 AM, Walker, Benjamin wrote:
>
> Currently we have no mechanism for adding device-specific quirks to the
> SPDK NVMe driver. We'd certainly consider adding quirks in the same
> fashion as the Linux kernel driver though, and would welcome patches
> that improved the applicability of SPDK to a wider range of (potentially
> out of spec) devices. I'm sure over time the team at Intel working on
> SPDK will add this, but it is not on our immediate roadmap, so patches
> from the community would be the best way to get this going.
>
> Thanks,
> Ben
The SPDK NVMe driver does have a quirk system that is currently used only
for Intel-specific quirks (see lib/nvme/nvme_intel.c); however, the
structure used just matches against a PCI device ID in a generic way, so we
should be able to extend this for use with other devices.
I think the ideal first patch to add such a quirk would be to rename the
nvme_intel file and structures to be generic. Then we could add new quirk
flags to describe whatever non-spec-compliant behavior is required to make
these devices work.
Thanks,
-- Daniel
_______________________________________________
SPDK mailing list
SPDK(a)lists.01.org
https://lists.01.org/mailman/listinfo/spdk
9:33 a.m.
We'd love to have you submit a patch to make nvme_intel.c generic (nvme_quirks.c).
Please go ahead.
On Wed, 2016-09-28 at 10:16 +0800, Wang Weber wrote:
Thanks for the information.
Is there a plan to update nvme_intel.c to be geneirc? or may I modify
it and upload the patch to the community? Thanks.
2016-09-13 0:20 GMT+08:00 Daniel Verkamp
<daniel.verkamp@intel.com<mailto:daniel.verkamp@intel.com>>:
On 09/09/2016 11:03 AM, Walker, Benjamin wrote:
Currently we have no mechanism for adding device-specific quirks to the
SPDK NVMe driver. We'd certainly consider adding quirks in the same
fashion as the Linux kernel driver though, and would welcome patches
that improved the applicability of SPDK to a wider range of (potentially
out of spec) devices. I'm sure over time the team at Intel working on
SPDK will add this, but it is not on our immediate roadmap, so patches
from the community would be the best way to get this going.
Thanks,
Ben
The SPDK NVMe driver does have a quirk system that is currently used only
for Intel-specific quirks (see lib/nvme/nvme_intel.c); however, the
structure used just matches against a PCI device ID in a generic way, so we
should be able to extend this for use with other devices.
I think the ideal first patch to add such a quirk would be to rename the
nvme_intel file and structures to be generic. Then we could add new quirk
flags to describe whatever non-spec-compliant behavior is required to make
these devices work.
Thanks,
-- Daniel
_______________________________________________
SPDK mailing list
SPDK@lists.01.org<mailto:SPDK@lists.01.org>
https://lists.01.org/mailman/listinfo/spdk
_______________________________________________
SPDK mailing list
SPDK@lists.01.org<mailto:SPDK@lists.01.org>
https://lists.01.org/mailman/listinfo/spdk
2101
days inactive
2121
days old
4 comments
3 participants
participants (3)
-
Daniel Verkamp -
Walker, Benjamin -
Wang Weber