1. 15 7月, 2014 2 次提交
    • A
      libata: EH should handle AMNF error condition as a media error · eec7e1c1
      Alexey Asemov 提交于
      libata-eh.c should handle AMNF error condition (error byte bit 0,
      usually code 0x01) in libata-eh.c along with UNC as a media error so
      SCSI stack can handle it properly (translation code 0x01 is already
      present in libata-scsi.c) but was never passed down due to lack of
      handling in EH.
      
      While using linux-based machine (AMD 6550M-based notebook, PCI IDs for the
      controller are 1022:7801 subsys 1025:059d) and ddrescue to salvage data
      from failing hard drive (WD7500BPVT 2.5" 750G SATA2), I've found that pure
      AMNF 0x01 error code generates generic "device error" that is retried
      several times by SCSI stack instead of "media error" that is passed up to
      software.
      
      So we may assume deprecated AMNF error code is surely not dead yet, and
      it's better for it to be handled properly. As we may see it is used by
      modern enough devices, and used properly: drive returned AMNF only when IDs
      for track cannot be read completely due to dying head or positioning,
      otherwise it returned UNC(orrectables).
      
      Not handling it causes wrong generic error code ("device error") reporting
      down the stack, can damage failing drives further because of excessive
      retries, and slows salvaging down a lot. Also, there is handling code in
      libata-scsi.c for 0x01 AMNF error already.
      
      https://bugzilla.kernel.org/show_bug.cgi?id=80031
      
      tj: Shortened $SUBJ and moved its content to the first paragraph.
      Signed-off-by: NAlexey Asemov <alex@alex-at.ru>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      eec7e1c1
    • K
      libata: support the ata host which implements a queue depth less than 32 · 1871ee13
      Kevin Hao 提交于
      The sata on fsl mpc8315e is broken after the commit 8a4aeec8
      ("libata/ahci: accommodate tag ordered controllers"). The reason is
      that the ata controller on this SoC only implement a queue depth of
      16. When issuing the commands in tag order, all the commands in tag
      16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
      malfunction. It makes no senses to use a 32 queue in software while
      the hardware has less queue depth. So consider the queue depth
      implemented by the hardware when requesting a command tag.
      
      Fixes: 8a4aeec8 ("libata/ahci: accommodate tag ordered controllers")
      Cc: stable@vger.kernel.org
      Signed-off-by: NKevin Hao <haokexin@gmail.com>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      1871ee13
  2. 08 7月, 2014 2 次提交
  3. 25 6月, 2014 2 次提交
  4. 19 6月, 2014 1 次提交
    • S
      ahci: imx: manage only sata_ref_clk in imx_sata_enable[disable] · e6dd42a9
      Shawn Guo 提交于
      Doing suspend/resume on imx6q and imx53 boards with no SATA disk
      attached will trigger the following warning.
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 661 at drivers/ata/libahci.c:224 ahci_enable_ahci+0x74/0x8)
      Modules linked in:
      CPU: 0 PID: 661 Comm: sh Tainted: G        W     3.15.0-rc5-next-20140521-000027
      Backtrace:
      [<80011c90>] (dump_backtrace) from [<80011e2c>] (show_stack+0x18/0x1c)
       r6:803a22f4 r5:00000000 r4:00000000 r3:00000000
      [<80011e14>] (show_stack) from [<80661e60>] (dump_stack+0x88/0xa4)
      [<80661dd8>] (dump_stack) from [<80028fdc>] (warn_slowpath_common+0x70/0x94)
       r5:00000009 r4:00000000
      [<80028f6c>] (warn_slowpath_common) from [<80029024>] (warn_slowpath_null+0x24/)
       r8:808f68c4 r7:00000000 r6:00000000 r5:00000000 r4:e0810004
      [<80029000>] (warn_slowpath_null) from [<803a22f4>] (ahci_enable_ahci+0x74/0x80)
      [<803a2280>] (ahci_enable_ahci) from [<803a2324>] (ahci_reset_controller+0x24/0)
       r8:ddcd9410 r7:80351178 r6:ddcd9444 r5:dde8b850 r4:e0810000 r3:ddf35e90
      [<803a2300>] (ahci_reset_controller) from [<803a2c68>] (ahci_platform_resume_ho)
       r7:80351178 r6:ddcd9444 r5:dde8b850 r4:ddcd9410
      [<803a2c30>] (ahci_platform_resume_host) from [<803a38f0>] (imx_ahci_resume+0x2)
       r5:00000000 r4:ddcd9410
      [<803a38c4>] (imx_ahci_resume) from [<803511ac>] (platform_pm_resume+0x34/0x54)
      ....
      
      The reason is that the SATA controller has no working clock at this
      point, and thus ahci_enable_ahci() fails to enable the controller.  In
      case that there is no SATA disk attached, the imx_sata_disable() gets
      called in ahci_imx_error_handler(), and both sata_clk and sata_ref_clk
      will be disabled there.  Because all the imx_sata_enable() calls
      afterward will return immediately due to imxpriv->no_device check, the
      SATA controller working clock sata_clk will never get any chance to be
      enabled again.
      
      This is a regression caused by commit 90870d79 (ahci-imx: Port to
      library-ised ahci_platform).  Before the commit, only sata_ref_clk is
      managed by the driver in enable/disable function.  But after the commit,
      all the clocks are enabled/disabled in a row by ahci platform helpers
      ahci_platform_enable[disable]_clks.  Since ahb_clk is a bus clock which
      does not have gate at all, and i.MX low-power hardware module already
      manages sata_clk across suspend/resume cycle, the only clock that needs
      to be managed by software is sata_ref_clk.
      
      So instead of using ahci_platform_enable[disable]_clks to manage all
      the clocks in a row from imx_sata_enable[disable], we should manage
      only sata_ref_clk in there.
      Reported-by: NFabio Estevam <fabio.estevam@freescale.com>
      Fixes: 90870d79 (ahci-imx: Port to library-ised ahci_platform)
      Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      e6dd42a9
  5. 18 6月, 2014 1 次提交
  6. 16 6月, 2014 1 次提交
    • B
      Revert "offb: Add palette hack for little endian" · 68986c9f
      Benjamin Herrenschmidt 提交于
      This reverts commit e1edf18b.
      
      This patch was a misguided attempt at fixing offb for LE ppc64
      kernels on BE qemu but is just wrong ... it breaks real LE/LE
      setups, LE with real HW, and existing mixed endian systems
      that did the fight thing with the appropriate device-tree
      property. Bad reviewing on my part, sorry.
      
      The right fix is to either make qemu change its endian when
      the guest changes endian (working on that) or to use the
      existing foreign endian support.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      CC: <stable@vger.kernel.org> [v3.13+]
      ---
      68986c9f
  7. 15 6月, 2014 1 次提交
  8. 14 6月, 2014 2 次提交
  9. 13 6月, 2014 14 次提交
  10. 12 6月, 2014 14 次提交