1. 13 1月, 2015 1 次提交
    • S
      mpt2sas, mpt3sas: log exceeded temperature thresholds · 2d8ce8c9
      Sreekanth Reddy 提交于
      This patch will log a message when driver receives "Temperature Threshold
      exceeded" event from any temperature sensor.
      
      The message will look similar to like:
      mpt3sas0: Temperature Threshold flags a b c d exceeded for Sensor: x !!!
      mpt3sas0: Current Temp In Celsius: y
      
      where a b c d are threshold flags 0 1 2 3
      
      Change_set:
      1. Get the number of sensor count of this IOC by reading IO Unit page 8 at
         driver initialization time.
      2. Also unmask the Temperature Threshold Event at driver initialization
         time
      3. Whenever a MPI2_EVENT_TEMP_THRESHOLD event is received from the
         firmware, then print the sensor number, the maximum threshold number it
         has exceed and the current temperature of this sensor.
      Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      2d8ce8c9
  2. 09 1月, 2015 1 次提交
  3. 17 9月, 2014 4 次提交
    • S
      mpt3sas: Added Reply Descriptor Post Queue (RDPQ) Array support · 9b05c91a
      Sreekanth Reddy 提交于
      Up to now, Driver allocates a single contiguous block of memory
      pool for all reply queues and passes down a single address in the
      ReplyDescriptorPostQueueAddress field of the IOC Init Request
      Message to the firmware.
      
      When firmware receives this address, it will program each of the
      Reply Descriptor Post Queue registers, as each reply queue has its
      own register. Thus the firmware, starting from a base address it
      determines the starting address of the subsequent reply queues
      through some simple arithmetic calculations.
      
      The size of this contiguous block of memory pool is directly proportional
      to number of MSI-X vectors and the HBA queue depth. For example higher
      MSIX vectors requires larger contiguous block of memory pool.
      
      But some of the OS kernels are unable to allocate this larger
      contiguous block of memory pool.
      
      So, the proposal is to allocate memory independently for each
      Reply Queue and pass down all of the addresses to the firmware.
      Then the firmware will just take each address and program the value
      into the correct register.
      
      When HBAs with older firmware(i.e. without RDPQ capability) is used
      with this new driver then the max_msix_vectors value would be set
      to 8 by default.
      
      Change set in v1:
      
      1. Declared the _base_get_ioc_facts() functions at the beginning of the mpt3sas_base.c file
      instead of moving all these functions before mpt3sas_base_map_resources() function
              a. _base_wait_for_doorbell_int()
              b. _base_wait_for_doorbell_ack()
              c. _base_wait_for_doorbell_not_used()
              d. _base_handshake_req_reply_wait()
              e. _base_get_ioc_facts()
      
      2. Initially set the consistent DMA mask to 32 bit and then change it to 64 bit mask
      after allocating RDPQ pools by calling the function _base_change_consistent_dma_mask.
      This is to ensure that all the upper 32 bits of RDPQ entries's base address to be same.
      
      3. Reduced the redundancy between the RDPQ and non-RDPQ support in these following functions
              a. _base_release_memory_pools()
              b. _base_allocate_memory_pools()
              c. _base_send_ioc_init()
              d. _base_make_ioc_operational()
      Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      9b05c91a
    • S
      mpt3sas: Added OEM branding Strings · 1117b31a
      Sreekanth Reddy 提交于
      Added following branding Strings for Intel custom HBAs support.
      
      Driver String:                                  Vendor ID       Device ID       SubSystemVendor ID      SubSystemDevice ID
      Intel(R) Integrated RAID Module RMS3JC080       0x1000          0x0097          0x8086                  0x3521
      Intel(R) RAID Controller RS3GC008               0x1000          0x0097          0x8086                  0x3522
      Intel(R) RAID Controller RS3FC044               0x1000          0x0097          0x8086                  0x3523
      Intel(R) RAID Controller RS3UC080               0x1000          0x0097          0x8086                  0x3524
      Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      1117b31a
    • S
      mpt3sas: Copyright in driver sources is updated for year the 2014. · a4ffce0d
      Sreekanth Reddy 提交于
      Copyright in driver sources is updated for year the 2014.
      Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@avagotech.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      a4ffce0d
    • A
      mpt3sas: Use pci_enable_msix_exact() instead of pci_enable_msix() · 6bfa6907
      Alexander Gordeev 提交于
      As result of deprecation of MSI-X/MSI enablement functions
      pci_enable_msix() and pci_enable_msi_block() all drivers
      using these two interfaces need to be updated to use the
      new pci_enable_msi_range()  or pci_enable_msi_exact()
      and pci_enable_msix_range() or pci_enable_msix_exact()
      interfaces.
      Signed-off-by: NAlexander Gordeev <agordeev@redhat.com>
      Reviewed-by: NTomas Henzl <thenzl@redhat.com>
      Cc: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
      Cc: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
      Cc: support@lsi.com
      Cc: DL-MPTFusionLinux@lsi.com
      Cc: linux-scsi@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      6bfa6907
  4. 26 7月, 2014 2 次提交
  5. 15 1月, 2014 1 次提交
  6. 03 9月, 2013 1 次提交
    • S
      [SCSI] mpt3sas: Added a driver module parameter max_msix_vectors · 9c500060
      Sreekanth Reddy 提交于
      Added a driver module parameter max_msix_vectors. Using this module parameter
      the maximum number of MSI-X vectors could be set.
      
      The number of MSI-X vectors used would be the minimum of MSI-X vectors
      supported by the HBA, the number of CPU cores and the value set to
      max_msix_vectors module parameter.
      
      The default value of this module parameter is set to 8. The default value of
      this parameter is set to 8 inorder to reduce the amount of memory required for
      Reply Descriptor Post queue.  This is because with the higher MSI-X vectors,
      some times kernel is not able to allocate the requested amount of memory and
      crash is observed. To overcome this problem, the default value is set to 8.
      Signed-off-by: NSreekanth Reddy <Sreekanth.Reddy@lsi.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      9c500060
  7. 26 8月, 2013 1 次提交
  8. 09 7月, 2013 2 次提交
  9. 29 1月, 2013 2 次提交
  10. 01 12月, 2012 1 次提交
  11. 17 9月, 2012 1 次提交
  12. 24 8月, 2012 2 次提交
  13. 22 8月, 2012 1 次提交
    • S
      [SCSI] mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth... · 338b131a
      sreekanth.reddy@lsi.com 提交于
      [SCSI] mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line option to a very small value
      
      If the specified max_queue_depth setting is less than the
      expected number of internal commands, then driver will calculate
      the queue depth size to a negitive number. This negitive number
      is actually a very large number because variable is unsigned
      16bit integer. So, the driver will ask for a very large amount of
      memory for message frames and resulting into oops as memory
      allocation routines will not able to handle such a large request.
      
      So, in order to limit this kind of oops, The driver need to set
      the max_queue_depth to a scsi mid layer's can_queue value. Then
      the overall message frames required for IO is minimum of either
      (max_queue_depth plus internal commands) or the IOC global
      credits.
      Signed-off-by: NSreekanth Reddy <sreekanth.reddy@lsi.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      338b131a
  14. 06 6月, 2012 1 次提交
  15. 24 4月, 2012 4 次提交
  16. 28 3月, 2012 2 次提交
  17. 28 2月, 2012 1 次提交
  18. 19 2月, 2012 1 次提交
  19. 13 2月, 2012 1 次提交
  20. 15 12月, 2011 9 次提交
  21. 30 10月, 2011 1 次提交
    • N
      [SCSI] mpt2sas: New feature - Fast Load Support · 921cd802
      nagalakshmi.nandigama@lsi.com 提交于
      New feature Fast Load Support.
      
      (1)Asynchronous SCSI scanning: This will allow the drivers to scan
      for devices in parallel while other device drivers are loading at
      the same time. This will improve the amount of time it takes for the
      OS to load.
      
      (2) Reporting Devices while port enable is active: This feature will
      allow devices to be reported to OS immediately while port enable is
      active. The previous implementation waits for port enable to complete,
      and then report devices. This feature is only enabled on IT firmware
      configurations when there are no boot device configured in BIOS Configuration
      Utility, else the driver will wait till port enable completes reporting
      devices. For IR firmware, this feature is turned off. This feature is to
      address large SAS topologies (>100 drives) when the boot OS is using onboard
      SATA device, in other words, the boot devices is not
      connected to our controller.
      
      (3) Scanning for devices after diagnostic reset completes: A new routine
      _scsih_scan_start is added. This will scan the expander pages, IR pages,
      and sas device pages, then reporting new devices to SCSI Mid layer. It
      seems the driver is not supporting adding devices while diagnostic reset
      is active. Apparently this is due to the sanity checks on
      ioc->shost_recovery flag throughout the context of kernel work thread FIFO,
      and the mpt2sas_fw_work.
      Signed-off-by: NNagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      921cd802