1. 02 2月, 2021 2 次提交
  2. 19 1月, 2021 1 次提交
  3. 29 7月, 2020 1 次提交
  4. 08 7月, 2020 3 次提交
  5. 27 5月, 2020 2 次提交
  6. 10 5月, 2020 2 次提交
    • K
      nvme: define constants for identification values · 92decf11
      Keith Busch 提交于
      Improve code readability by defining the specification's constants that
      the driver is using when decoding identification payloads.
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      Reviewed-by: NBart van Assche <bvanassche@acm.org>
      Reviewed-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Acked-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      92decf11
    • C
      nvmet: align addrfam list to spec · d02abd19
      Chaitanya Kulkarni 提交于
      With reference to the NVMeOF Specification (page 44, Figure 38)
      discovery log page entry provides address family field. We do set the
      transport type field but the adrfam field is not set when using loop
      transport and also it doesn't have support in the nvme-cli. So when
      reading discovery log page with a loop transport it leads to confusing
      output.
      
      As per the spec for adrfam value 254 is reserved for Intra Host
      Transport i.e. loopback), we add a required macro in the protocol
      header file, set default port disc addr entry's adrfam to
      NVMF_ADDR_FAMILY_MAX, and update nvmet_addr_family configfs array for
      show/store attribute.
      
      Without this patch, setting adrfam to (ipv4/ipv6/ib/fc/loop/" ") we get
      following output for nvme discover command from nvme-cli which is
      confusing.
      trtype:  loop
      adrfam:  ipv4
      trtype:  loop
      adrfam:  ipv6
      trtype:  loop
      adrfam:  infiniband
      trtype:  loop
      adrfam:  fibre-channel
      trtype:  loop		# ${CFGFS_HOME}/nvmet/ports/1/addr_adrfam = loop
      adrfam:  pci            # <----- pci for loop
      trtype:  loop		# ${CFGFS_HOME}/nvmet/ports/1/addr_adrfam = " "
      adrfam:  pci            # <----- pci for unrecognized
      
      This patch fixes above output :-
      trtype:  loop
      adrfam:  ipv4
      trtype:  loop
      adrfam:  ipv6
      trtype:  loop
      adrfam:  infiniband
      trtype:  loop
      adrfam:  fibre-channel
      trtype:  loop           # ${CFGFS_HOME}/nvmet/ports/1/addr_adrfam = loop
      adrfam:  loop           # <----- loop for loop
      trtype:  loop		# ${CFGFS_HOME}/config/nvmet/ports/adrfam = " "
      adrfam:  unrecognized   # <----- unrecognized when invalid value
      Signed-off-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      d02abd19
  7. 22 11月, 2019 1 次提交
    • A
      nvme: hwmon: provide temperature min and max values for each sensor · 52deba0f
      Akinobu Mita 提交于
      According to the NVMe specification, the over temperature threshold and
      under temperature threshold features shall be implemented for Composite
      Temperature if a non-zero WCTEMP field value is reported in the Identify
      Controller data structure.  The features are also implemented for all
      implemented temperature sensors (i.e., all Temperature Sensor fields that
      report a non-zero value).
      
      This provides the over temperature threshold and under temperature
      threshold for each sensor as temperature min and max values of hwmon
      sysfs attributes.
      
      The WCTEMP is already provided as a temperature max value for Composite
      Temperature, but this change isn't incompatible.  Because the default
      value of the over temperature threshold for Composite Temperature is
      the WCTEMP.
      
      Now the alarm attribute for Composite Temperature indicates one of the
      temperature is outside of a temperature threshold.  Because there is only
      a single bit in Critical Warning field that indicates a temperature is
      outside of a threshold.
      
      Example output from the "sensors" command:
      
      nvme-pci-0100
      Adapter: PCI adapter
      Composite:    +33.9°C  (low  = -273.1°C, high = +69.8°C)
                             (crit = +79.8°C)
      Sensor 1:     +34.9°C  (low  = -273.1°C, high = +65261.8°C)
      Sensor 2:     +31.9°C  (low  = -273.1°C, high = +65261.8°C)
      Sensor 5:     +47.9°C  (low  = -273.1°C, high = +65261.8°C)
      
      This also adds helper macros for kelvin from/to milli Celsius conversion,
      and replaces the repeated code in hwmon.c.
      
      Cc: Keith Busch <kbusch@kernel.org>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: Jean Delvare <jdelvare@suse.com>
      Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      52deba0f
  8. 05 11月, 2019 2 次提交
  9. 30 8月, 2019 3 次提交
  10. 10 7月, 2019 1 次提交
  11. 21 6月, 2019 3 次提交
  12. 14 5月, 2019 1 次提交
  13. 11 4月, 2019 1 次提交
  14. 20 2月, 2019 1 次提交
  15. 13 12月, 2018 3 次提交
  16. 08 12月, 2018 8 次提交
  17. 02 10月, 2018 1 次提交
    • J
      nvme: call nvme_complete_rq when nvmf_check_ready fails for mpath I/O · 783f4a44
      James Smart 提交于
      When an io is rejected by nvmf_check_ready() due to validation of the
      controller state, the nvmf_fail_nonready_command() will normally return
      BLK_STS_RESOURCE to requeue and retry.  However, if the controller is
      dying or the I/O is marked for NVMe multipath, the I/O is failed so that
      the controller can terminate or so that the io can be issued on a
      different path.  Unfortunately, as this reject point is before the
      transport has accepted the command, blk-mq ends up completing the I/O
      and never calls nvme_complete_rq(), which is where multipath may preserve
      or re-route the I/O. The end result is, the device user ends up seeing an
      EIO error.
      
      Example: single path connectivity, controller is under load, and a reset
      is induced.  An I/O is received:
      
        a) while the reset state has been set but the queues have yet to be
           stopped; or
        b) after queues are started (at end of reset) but before the reconnect
           has completed.
      
      The I/O finishes with an EIO status.
      
      This patch makes the following changes:
      
        - Adds the HOST_PATH_ERROR pathing status from TP4028
        - Modifies the reject point such that it appears to queue successfully,
          but actually completes the io with the new pathing status and calls
          nvme_complete_rq().
        - nvme_complete_rq() recognizes the new status, avoids resetting the
          controller (likely was already done in order to get this new status),
          and calls the multipather to clear the current path that errored.
          This allows the next command (retry or new command) to select a new
          path if there is one.
      Signed-off-by: NJames Smart <jsmart2021@gmail.com>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      783f4a44
  18. 08 8月, 2018 2 次提交
  19. 28 7月, 2018 2 次提交