[Bug 221616] incorrect nvme driver init sequence

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Aug 18 21:00:21 UTC 2017


            Bug ID: 221616
           Summary: incorrect nvme driver init sequence
           Product: Base System
           Version: 10.3-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: kinjal.patel at taec.toshiba.com

Created attachment 185557
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185557&action=edit
patch to correct the NVMe driver init sequence

At present, the NVMe driver init sequence is,
1)      Enable controller (CC.EN=1)
2)      Wait for controller ready (CSTS.RDY=1)
3)      Set PCI bus master enable (BME=1)

As per NVMe spec, when NVMe controller becomes ready it has to process command.

"Enable (EN): When set to '1', then the controller shall process commands based
on Submission Queue Tail doorbell writes"

And per PCI Express spec when BME is not set, the PCI Express Function is not
allowed to issue any Memory or I/O requests.
"Bus Master Enable - Controls the ability of a PCI Express Endpoint to issue
Memory95 and I/O Read/Write Requests, and
the ability of a Root or Switch Port to forward Memory and I/O Read/Write
Requests in the Upstream direction"

Enabling controller before setting BME=1 is violation of spec, as controller 
has to accept commands but BME is prerequisite for that.

The FreeBSD NVMe driver sequence should be changed to set BME=1 before
attempting to enable controller.

The Linux device driver init sequence also does the same. That is,
1)     Set PCI bus master enable (BME=1)
2)     Enable Controller (CC.EN=1)
3)     Wait for controller ready (CSTS.RDY=1)

Please find attached patch to correct the NVMe driver init sequence.
The patch is based on "FreeBSD 10.3-STABLE amd64" source.

Kinjal Patel

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list