1. 13 Aug, 2019 32 commits
  2. 08 Aug, 2019 8 commits
    • Suganath Prabu's avatar
      scsi: mpt3sas: Update driver version to 31.100.00.00 · 6e0b7ca2
      Suganath Prabu authored
      Updated driver version from 29.100.00.00 to 31.100.00.00 which is
      equivalent to Phase 12 OOB.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      6e0b7ca2
    • Suganath Prabu's avatar
      scsi: mpt3sas: Run SAS DEVICE STATUS CHANGE EVENT from ISR · 54d74e6b
      Suganath Prabu authored
      In some cases, like while performing extensive expander reset or phy reset,
      user may observe that drives are not visible in OS. Driver's
      firmware-worker thread is blocked for more than 120 seconds resulting in a
      call trace.
      
      1. Received target add event for Device A and hence driver has registered
      this device to SML by calling sas_rphy_add(). SML has half added this
      device and returned the control to the driver by quitting from
      sas_rphy_add() API, and started some background scanning on this device A.
      
      2. While background scanning is going on device A, driver has received SAS
      DEVICE STATUS CHANGE EVENT with RC code "Internal device reset" event and
      hence driver has set tm_busy flag for this Device A from FW worker thread
      context. When tm_busy flag is set then driver return scsi commands with
      device busy status asking the kernel to retry the command after some time.
      So background scanning for device A will be waiting for this tm_busy to be
      cleared.
      
      3. Meanwhile driver has received a target add event for Device B and hence
      driver called sas_rphy_add() API to register this device with SML. But
      since background scanning for Device A is still pending and SML is not
      quitting from sas_rphy_add(), the driver’s firmware worker thread got
      blocked.
      
      4. Now driver has received SAS DEVICE STATUS CHANGE EVENT with RC code
      "Internal device reset complete" event. But as driver’s firmware worker
      thread got blocked in Step3, it can’t process this event and it was not
      clearing the tm_busy flag and deadlock occurred (where SML was waiting for
      tm_busy flag to be cleared and our FW worker thread is waiting for SML to
      quit from sas_device_rphy_add() API).
      
      Same deadlock will be observed even if device B is getting removed in
      step3. So to limit these types of deadlocks driver will process the SAS
      DEVICE STATUS CHANGE EVENT events from ISR context instead of processing
      this event from worker thread context.  This improvement avoids above
      deadlock.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      54d74e6b
    • Suganath Prabu's avatar
      scsi: mpt3sas: Reduce the performance drop · 1edc6770
      Suganath Prabu authored
      This patch is to reduce the performance drop depth observed on SATA HDD
      when ATA PT command is outstanding.
      
      Driver returns IO commands with status "SAM_STAT_BUSY" whenever ATA PT
      command is outstanding. With this, IO commands will be retried until this
      outstanding ATA PT to complete and hence we will observe drop in
      performance.
      
      As the driver is completing the subsequent IOs commands with SAM_STAT_BUSY
      status, these IOs has to go though the block layer.  Hence it adds latency
      to the IOs and large performance drop is observed.
      
      So to reduce this performance dropp, added improvement in driver to return
      the subsequent IOs with SCSI_MLQUEUE_DEVICE_BUSY status instead of
      completing the IOs with SAM_STAT_BUSY status when ATA PT command is
      outstanding. Sending command back with SCSI_MLQUEUE_DEVICE_BUSY does not go
      through complete block layer stack (as scsi_done won't be called) SML will
      immediately retry the command and this method will avoid latency of block
      layer stack and the performance impact will be reduced.
      
      On Local setup, ran 512k sequential read IO operation on HGST SATA drive
      with existing driver & with this improvement drivers and here is the
      result,
      
      1. With existing driver: IOs are running at bandwidth of ~230 rMB/s and
      whenever any ATA PT command is outstanding (e.g issued from systemd-udevd
      daemon) then this bandwidth drops to ~150 rMB/s.
      
      2. With this improvement driver: IOs are running at bandwidth of ~230 rMB/s
      and whenever any ATA PT command is outstanding then this bandwidth drops to
      just ~190 rMB/s.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      1edc6770
    • Suganath Prabu's avatar
      scsi: mpt3sas: Handle fault during HBA initialization · 9c067c05
      Suganath Prabu authored
      During HBA initialization time, if handshake operation fails due to some
      firmware fault then currently driver is terminating the HBA
      initialization. It is possible that HBA may come up properly if diag reset
      is issued.
      
      So improvement is made in driver in such a way that before terminating the
      HBA initialization, driver checks the IOC state and if IOC state is in
      fault state then issue diag reset for once. If diag reset is successful
      then continue with HBA initialization else terminate the HBA
      initialization.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      9c067c05
    • Suganath Prabu's avatar
      scsi: mpt3sas: Add sysfs to know supported features · 3ac8e47b
      Suganath Prabu authored
      Currently with sysfs parameter "drv_support_bitmap" driver exposes whether
      driver supports toolbox memory move command or not.
      
      And application should issue the toolbox memory move command only if driver
      tell that memory move tool box command is supported through this sysfs
      parameter.
      
      In future we can utilize this sysfs parameter if any new feature is added
      and need to notify the same to applications.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      3ac8e47b
    • Suganath Prabu's avatar
      scsi: mpt3sas: Support MEMORY MOVE Tool box command · ba630ea0
      Suganath Prabu authored
      Host uses the Memory Move Tool to copy data from any source/destination
      combination of system memory and IOC memory.
      
      Memory Move Tool box request contains two SGE fields, First SGE field must
      contains the source buffer details described by an MPI Simple SGE.  The
      second SGE field must contains the destination buffer details described by
      an MPI Simple SGE.
      
       Source   ->   Destination
      
      1. IOC    ->   IOC    (Both the SGE's will be filled by application)
      
      2. HOST   ->   HOST   (Both the SGE's will be filled by the host,
                     application should give sgl_offset to first SGE offset)
      
      3. IOC    ->   HOST   (Application will fill the first SGE and set the
                     sgl_offset to second SGE and hence driver fills
                     the second SGE)
      4. HOST   ->   IOC    (Application will fill IOC buffer information in the
                     first SGE and set the sgl_offset to second SGE.
                     Then driver will fill the second SGE with Host buffer
                     information and just before posting the command to the
                     firmware, driver will swap these two SGEs so that first
                     SGE contains the HOST buffer information and second SGE
                     contains the IOC information.
      
      Driver has to take care only of the 4th case, other three cases are by
      default supported by the current driver design.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      ba630ea0
    • Suganath Prabu's avatar
      scsi: mpt3sas: Allow ioctls to blocked access status NVMe · 3c090ce3
      Suganath Prabu authored
      If driver sees the NVMe drive with "DEVICE_BLOCKED" AccessStatus in its
      PCIe Device Page0, then driver removes the drive from its internal list and
      does not allow any IOCTL commands to be sent to the drive and will return
      the IOCTLs with "-ENODEV" status.
      
      The driver will now allow NVMe Encapsulated IOCTL issued to the NVMe device
      with an access status of DEVICE_BLOCKED. This change allows the user to
      flash new drive firmware online and revive the drive.
      
      Add NVMe device only the driver's internal list even though the device is
      in the blocked state so that the device will be visible to Apps. This way
      Apps can send NVMe Encapsulated IOCTLs to this drive and bring the drive
      online. This NVMe drive with DEVICE_BLOCKED access status won't added to
      the SML, it will be added only in the driver's internal list.
      
      [mkp: clarified desc]
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      3c090ce3
    • Suganath Prabu's avatar
      scsi: mpt3sas: Enumerate SES of a managed PCIe switch · 5bb309db
      Suganath Prabu authored
      SES device of managed PCIe switch will be enumerated same as NVMe drives.
      
      The device info type for this SES device is
      
              MPI26_PCIE_DEVINFO_SCSI (0x4),
      
      whereas the device info type for NVMe drives is
      
              MPI26_PCIE_DEVINFO_NVME (0x3).
      
      Based on this device info type driver determines whether the device is NVMe
      drive or a SES device of a managed PCIe switch.
      
      This SES device doesn't have the PCIe device page 2 information like NVMe
      drives, so driver won't read PCIe device page 2 information for SES device.
      
      This SES device uses only IEEE SGL's, So driver build's IEEE SGL's whenever
      it receives any SCSI commands for this SES device.
      Signed-off-by: default avatarSuganath Prabu <suganath-prabu.subramani@broadcom.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      5bb309db