1. 03 12月, 2012 1 次提交
    • S
      libata: check SATA_SETTINGS log with HW Feature Ctrl · de90cd71
      Shane Huang 提交于
      NCQ capability was used to check availability of SATA Settings page
      from Identify Device Data Log, which contains DevSlp timing variables.
      It does not work on some HDDs and leads to error messages.
      IDENTIFY word 78 bit 5(Hardware Feature Control) should be used.
      
      Quoting SATA spec 3.1:
      If Hardware Feature Control is supported, then:
      a) IDENTIFY DEVICE data word 78 bit 5 (see 13.2.1.18) shall be
      set to one;
      b) the SET FEATURES Select Hardware Feature Control subcommand
      shall be supported (see 13.3.8);
      c) page 08h of the Identify Device Data log (see 13.7.7) shall
      be supported;
      
      This patch is not tested on SATA HDD with DevSlp supported.
      Reported-by: NBorislav Petkov <bp@amd64.org>
      Signed-off-by: NShane Huang <shane.huang@amd.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      de90cd71
  2. 13 9月, 2012 2 次提交
  3. 29 6月, 2012 1 次提交
  4. 15 3月, 2011 1 次提交
  5. 14 3月, 2011 1 次提交
  6. 22 10月, 2010 1 次提交
  7. 20 5月, 2010 1 次提交
  8. 09 4月, 2010 1 次提交
  9. 02 3月, 2010 1 次提交
    • B
      ata: Detect Delkin Devices compact flash · 4b7d1c05
      Ben Gardner 提交于
      I have a Delkin Devices compact flash card that isn't being recognized using the
      SATA/PATA drivers.
      The card is recognized and works with the deprecated ATA drivers.
      
      The error I am seeing is:
      ata1.00: failed to IDENTIFY (device reports invalid type, err_mask=0x0)
      
      I tracked it down to ata_id_is_cfa() in include/linux/ata.h.
      The Delkin card has id[0] set to 0x844a and id[83] set to 0.
      This isn't what the kernel expects and is probably incorrect.
      
      The simplest work-around is to add a check for 0x844a to ata_id_is_cfa().
      Signed-off-by: NBen Gardner <gardner.ben@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      4b7d1c05
  10. 04 2月, 2010 1 次提交
  11. 04 12月, 2009 2 次提交
  12. 03 12月, 2009 1 次提交
    • C
      libata: add translation for SCSI WRITE SAME (aka TRIM support) · 18f0f978
      Christoph Hellwig 提交于
      Add support for the ATA TRIM command in libata.  We translate a WRITE SAME 16
      command with the unmap bit set into an ATA TRIM command and export enough
      information in READ CAPACITY 16 and the block limits EVPD page so that the new
      SCSI layer discard support will driver this for us.
      
      Note that I hardcode the WRITE_SAME_16 opcode for now as the patch to introduce
      the symbolic is not in 2.6.32 yet but only in the SCSI tree - as soon as it is
      merged we can fix it up to properly use the symbolic name.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      18f0f978
  13. 06 10月, 2009 2 次提交
  14. 02 9月, 2009 2 次提交
    • R
      libata: add command name parsing for error output · 6521148c
      Robert Hancock 提交于
      This patch improve libata's output for error/notification messages
      to allow easier comprehension and debugging:
      
      When ATAPI commands issued through the SCSI layer fail, use SCSI
      functions to print the CDB in human-readable form instead of just
      dumping out the CDB in hex.
      
      Print out the name of the failed command (as defined by the ATA
      specification) in error handling output along with the raw register
      contents.
      
      When reporting status of ACPI taskfile commands executed on resume,
      also output the names of the commands being executed (or not) in
      readable form.
      
      Since the extra data for printing command names increases kernel
      size slightly, a config option has been added to allow disabling
      command name output (as well as some of the error register parsing)
      for those highly sensitive to kernel text size.
      Signed-off-by: NRobert Hancock <hancockrwd@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      6521148c
    • S
      [libata] add DMA setup FIS auto-activate feature · 388539f3
      Shaohua Li 提交于
      Hopefully results in fewer on-the-wire FIS's and no breakage.  We'll see!
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      388539f3
  15. 16 6月, 2009 1 次提交
  16. 16 5月, 2009 1 次提交
    • M
      libata: Media rotation rate and form factor heuristics · 4bca3286
      Martin K. Petersen 提交于
      This patch provides new heuristics for parsing both the form factor and
      media rotation rate ATA IDENFITY words.
      
      The reported ATA version must be 7 or greater and the device must return
      values defined as valid in the standard.  Only then are the
      characteristics reported to SCSI via the VPD B1 page.
      
      This seems like a reasonable compromise to me considering that we have
      been shipping several kernel releases that key off the rotation rate bit
      without any version checking whatsoever.  With no complaints so far.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      4bca3286
  17. 07 4月, 2009 1 次提交
  18. 25 3月, 2009 2 次提交
  19. 06 3月, 2009 1 次提交
  20. 03 2月, 2009 1 次提交
  21. 11 10月, 2008 6 次提交
  22. 09 10月, 2008 1 次提交
  23. 29 9月, 2008 1 次提交
  24. 14 9月, 2008 1 次提交
    • T
      [libata] LBA28/LBA48 off-by-one bug in ata.h · 97b697a1
      Taisuke Yamada 提交于
      I recently bought 3 HGST P7K500-series 500GB SATA drives and
      had trouble accessing the block right on the LBA28-LBA48 border.
      Here's how it fails (same for all 3 drives):
      
        # dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null
        dd: reading `/dev/sdc': Input/output error
        0+0 records in
        0+0 records out
        0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s
        # dmesg
        ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
        ata1.00: BMDMA stat 0x25
        ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in
        res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error)
        ata1.00: status: { DRDY ERR }
        ata1.00: error: { ABRT }
        ata1.00: configured for UDMA/33
        ata1: EH complete
        ...
      
      After some investigations, it turned out this seems to be caused
      by misinterpretation of the ATA specification on LBA28 access.
      Following part is the code in question:
      
        === include/linux/ata.h ===
        static inline int lba_28_ok(u64 block, u32 n_block)
        {
          /* check the ending block number */
          return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
        }
      
      HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff,
      n_block = 1}, and this behavior seems to be comformant. Other drives,
      including other HGST drives are not that strict, through.
      
      >From the ATA specification:
      (http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf)
      
        8.15.29  Word (61:60): Total number of user addressable sectors
        This field contains a value that is one greater than the total number
        of user addressable sectors (see 6.2). The maximum value that shall
        be placed in this field is 0FFFFFFFh.
      
      So the driver shouldn't use the value of 0xfffffff for LBA28 request
      as this exceeds maximum user addressable sector. The logical maximum
      value for LBA28 is 0xffffffe.
      
      The obvious fix is to cut "- 1" part, and the patch attached just do
      that. I've been using the patched kernel for about a month now, and
      the same fix is also floating on the net for some time. So I believe
      this fix works reliably.
      
      Just FYI, many Windows/Intel platform users also seems to be struck
      by this, and HGST has issued a note pointing to Intel ICH8/9 driver.
      
        "28-bit LBA command is being used to access LBAs 29-bits in length"
      http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23
      
      Also, *BSDs seems to have similar fix included sometime around ~2004,
      through I have not checked out exact portion of the code.
      Signed-off-by: NTaisuke Yamada <tai@rakugaki.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      97b697a1
  25. 19 8月, 2008 3 次提交
  26. 24 2月, 2008 1 次提交
    • T
      libata: automatically use DMADIR if drive/bridge requires it · 91163006
      Tejun Heo 提交于
      Back in 2.6.17-rc2, a libata module parameter was added for atapi_dmadir.
      
      That's nice, but most SATA devices which need it will tell us about it
      in their IDENTIFY PACKET response, as bit-15 of word-62 of the
      returned data (as per ATA7, ATA8 specifications).
      
      So for those which specify it, we should automatically use the DMADIR bit.
      Otherwise, disc writing will fail by default on many SATA-ATAPI drives.
      
      This patch adds ATA_DFLAG_DMADIR and make ata_dev_configure() set it
      if atapi_dmadir is set or identify data indicates DMADIR is necessary.
      atapi_xlat() is converted to check ATA_DFLAG_DMADIR before setting
      DMADIR.
      
      Original patch is from Mark Lord.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: Mark Lord <mlord@pobox.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      91163006
  27. 23 1月, 2008 2 次提交