1. 04 1月, 2022 1 次提交
  2. 12 11月, 2021 1 次提交
    • D
      libata: add horkage for missing Identify Device log · 636f6e2a
      Damien Le Moal 提交于
      ACS-3 introduced the ATA Identify Device Data log as mandatory. A
      warning message currently signals to the user if a device does not
      report supporting this log page in the log directory page, regardless
      of the ATA version of the device. Furthermore, this warning will appear
      for all attempts at accessing this missing log page during device
      revalidation.
      
      Since it is useless to constantly access the log directory and warn
      about this lack of support once we have discovered that the device
      does not support this log page, introduce the horkage flag
      ATA_HORKAGE_NO_ID_DEV_LOG to mark a device as lacking support for
      the Identify Device Data log page. Set this flag when
      ata_log_supported() returns false in ata_identify_page_supported().
      The warning is printed only if the device ATA level is 10 or above
      (ACS-3 or above), and only once on device scan. With this flag set, the
      log directory page is not accessed again to test for Identify Device
      Data log page support.
      Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      636f6e2a
  3. 11 11月, 2021 1 次提交
    • D
      libata: fix read log timeout value · 68dbbe7d
      Damien Le Moal 提交于
      Some ATA drives are very slow to respond to READ_LOG_EXT and
      READ_LOG_DMA_EXT commands issued from ata_dev_configure() when the
      device is revalidated right after resuming a system or inserting the
      ATA adapter driver (e.g. ahci). The default 5s timeout
      (ATA_EH_CMD_DFL_TIMEOUT) used for these commands is too short, causing
      errors during the device configuration. Ex:
      
      ...
      ata9: SATA max UDMA/133 abar m524288@0x9d200000 port 0x9d200400 irq 209
      ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
      ata9.00: ATA-9: XXX  XXXXXXXXXXXXXXX, XXXXXXXX, max UDMA/133
      ata9.00: qc timeout (cmd 0x2f)
      ata9.00: Read log page 0x00 failed, Emask 0x4
      ata9.00: Read log page 0x00 failed, Emask 0x40
      ata9.00: NCQ Send/Recv Log not supported
      ata9.00: Read log page 0x08 failed, Emask 0x40
      ata9.00: 27344764928 sectors, multi 16: LBA48 NCQ (depth 32), AA
      ata9.00: Read log page 0x00 failed, Emask 0x40
      ata9.00: ATA Identify Device Log not supported
      ata9.00: failed to set xfermode (err_mask=0x40)
      ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
      ata9.00: configured for UDMA/133
      ...
      
      The timeout error causes a soft reset of the drive link, followed in
      most cases by a successful revalidation as that give enough time to the
      drive to become fully ready to quickly process the read log commands.
      However, in some cases, this also fails resulting in the device being
      dropped.
      
      Fix this by using adding the ata_eh_revalidate_timeouts entries for the
      READ_LOG_EXT and READ_LOG_DMA_EXT commands. This defines a timeout
      increased to 15s, retriable one time.
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDamien Le Moal <damien.lemoal@opensource.wdc.com>
      68dbbe7d
  4. 27 10月, 2021 1 次提交
  5. 17 10月, 2021 1 次提交
  6. 03 9月, 2021 1 次提交
  7. 25 8月, 2021 1 次提交
  8. 18 8月, 2021 2 次提交
  9. 16 6月, 2021 1 次提交
  10. 03 9月, 2020 1 次提交
    • T
      libata: implement ATA_HORKAGE_MAX_TRIM_128M and apply to Sandisks · 3b545563
      Tejun Heo 提交于
      All three generations of Sandisk SSDs lock up hard intermittently.
      Experiments showed that disabling NCQ lowered the failure rate significantly
      and the kernel has been disabling NCQ for some models of SD7's and 8's,
      which is obviously undesirable.
      
      Karthik worked with Sandisk to root cause the hard lockups to trim commands
      larger than 128M. This patch implements ATA_HORKAGE_MAX_TRIM_128M which
      limits max trim size to 128M and applies it to all three generations of
      Sandisk SSDs.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Karthik Shivaram <karthikgs@fb.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      3b545563
  11. 24 6月, 2020 1 次提交
  12. 18 6月, 2020 1 次提交
  13. 16 6月, 2020 2 次提交
  14. 23 4月, 2020 1 次提交
  15. 27 3月, 2020 15 次提交
  16. 12 3月, 2020 1 次提交
  17. 30 1月, 2020 1 次提交
  18. 03 1月, 2020 1 次提交
    • A
      compat_ioctl: scsi: handle HDIO commands from drivers · 75c0b0e1
      Arnd Bergmann 提交于
      The ata_sas_scsi_ioctl() function implements a number of HDIO_* commands
      for SCSI devices, it is used by all libata drivers as well as a few
      drivers that support SAS attached SATA drives.
      
      The only command that is not safe for compat ioctls here is
      HDIO_GET_32BIT. Change the implementation to check for in_compat_syscall()
      in order to do both cases correctly, and change all callers to use it
      as both native and compat callback pointers, including the indirect
      callers through sas_ioctl and ata_scsi_ioctl.
      Reviewed-by: NBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      75c0b0e1
  19. 26 12月, 2019 1 次提交
    • S
      libata: Fix retrieving of active qcs · 8385d756
      Sascha Hauer 提交于
      ata_qc_complete_multiple() is called with a mask of the still active
      tags.
      
      mv_sata doesn't have this information directly and instead calculates
      the still active tags from the started tags (ap->qc_active) and the
      finished tags as (ap->qc_active ^ done_mask)
      
      Since 28361c40 the hw_tag and tag are no longer the same and the
      equation is no longer valid. In ata_exec_internal_sg() ap->qc_active is
      initialized as 1ULL << ATA_TAG_INTERNAL, but in hardware tag 0 is
      started and this will be in done_mask on completion. ap->qc_active ^
      done_mask becomes 0x100000000 ^ 0x1 = 0x100000001 and thus tag 0 used as
      the internal tag will never be reported as completed.
      
      This is fixed by introducing ata_qc_get_active() which returns the
      active hardware tags and calling it where appropriate.
      
      This is tested on mv_sata, but sata_fsl and sata_nv suffer from the same
      problem. There is another case in sata_nv that most likely needs fixing
      as well, but this looks a little different, so I wasn't confident enough
      to change that.
      
      Fixes: 28361c40 ("libata: add extra internal command")
      Cc: stable@vger.kernel.org
      Tested-by: NPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      
      Add missing export of ata_qc_get_active(), as per Pali.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      8385d756
  20. 01 11月, 2019 2 次提交
  21. 21 5月, 2019 1 次提交
  22. 09 2月, 2019 1 次提交
  23. 19 12月, 2018 1 次提交