Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 7月, 2016 2 次提交
  3. 10 5月, 2016 3 次提交
  5. 05 4月, 2016 5 次提交
  7. 07 12月, 2015 1 次提交
  9. 04 8月, 2015 2 次提交
    • T
      Revert "libata: Implement NCQ autosense" · 74a80d67
      由 Tejun Heo 提交于 
      This reverts commit 42b966fb.

As implemented, ACS-4 sense reporting for ATA devices bypasses error
diagnosis and handling in libata degrading EH behavior significantly.
Revert the related changes for now.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>
Cc: stable@vger.kernel.org #v4.1+
      74a80d67
    • T
      Revert "libata: Implement support for sense data reporting" · 84ded2f8
      由 Tejun Heo 提交于 
      This reverts commit fe7173c2.

As implemented, ACS-4 sense reporting for ATA devices bypasses error
diagnosis and handling in libata degrading EH behavior significantly.
Revert the related changes for now.

ATA_ID_COMMAND_SET_3/4 constants are not reverted as they're used by
later changes.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>
Cc: stable@vger.kernel.org #v4.1+
      84ded2f8
  11. 03 8月, 2015 1 次提交
  13. 22 5月, 2015 1 次提交
  15. 05 5月, 2015 1 次提交
  17. 26 4月, 2015 1 次提交
  19. 27 3月, 2015 6 次提交
  21. 21 1月, 2015 1 次提交
  23. 09 1月, 2015 1 次提交
  25. 07 1月, 2015 1 次提交
  27. 06 1月, 2015 1 次提交
  29. 06 11月, 2014 1 次提交
  31. 15 7月, 2014 1 次提交
    • 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
  33. 19 3月, 2014 1 次提交
    • D
      libata, libsas: kill pm_result and related cleanup · bc6e7c4b
      由 Dan Williams 提交于 
      Tejun says:
  "At least for libata, worrying about suspend/resume failures don't make
   whole lot of sense.  If suspend failed, just proceed with suspend.  If
   the device can't be woken up afterwards, that's that.  There isn't
   anything we could have done differently anyway.  The same for resume, if
   spinup fails, the device is dud and the following commands will invoke
   EH actions and will eventually fail.  Again, there really isn't any
   *choice* to make.  Just making sure the errors are handled gracefully
   (ie. don't crash) and the following commands are handled correctly
   should be enough."

The only libata user that actually cares about the result from a suspend
operation is libsas.  However, it only cares about whether queuing a new
operation collides with an in-flight one.  All libsas does with the
error is retry, but we can just let libata wait for the previous
operation before continuing.

Other cleanups include:
1/ Unifying all ata port pm operations on an ata_port_pm_ prefix
2/ Marking all ata port pm helper routines as returning void, only
   ata_port_pm_ entry points need to fake a 0 return value.
3/ Killing ata_port_{suspend|resume}_common() in favor of calling
   ata_port_request_pm() directly
4/ Killing the wrappers that just do a to_ata_port() conversion
5/ Clearly marking the entry points that do async operations with an
  _async suffix.

Reference: http://marc.info/?l=linux-scsi&m=138995409532286&w=2

Cc: Phillip Susi <psusi@ubuntu.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NTodd Brandt <todd.e.brandt@intel.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
      bc6e7c4b
  35. 08 3月, 2014 1 次提交
    • D
      libata: end the r-word · 35bf8821
      由 Dan Williams 提交于 
      Prompted by the social effort in the US to discourage usage of the
adjective "retarded".

In this case we needlessly anthropomorphize hard drives.  The
implication is that due to design deficiencies in the device reset
recovery time is negatively impacted.  We can simply clearly state that
fact.  "Exceptional devices cause outliers in reset recovery time." This
steers clear of any unintended comparison of such devices to humans with
cognitive disabilities.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
      35bf8821
  37. 23 11月, 2013 1 次提交
  39. 15 11月, 2013 1 次提交
  41. 27 10月, 2013 1 次提交
  43. 08 10月, 2013 1 次提交
    • G
      libata: make ata_eh_qc_retry() bump scmd->allowed on bogus failures · f13e2201
      由 Gwendal Grignou 提交于 
      libata EH decrements scmd->retries when the command failed for reasons
unrelated to the command itself so that, for example, commands aborted
due to suspend / resume cycle don't get penalized; however,
decrementing scmd->retries isn't enough for ATA passthrough commands.

Without this fix, ATA passthrough commands are not resend to the
drive, and no error is signalled to the caller because:

- allowed retry count is 1
- ata_eh_qc_complete fill the sense data, so result is valid
- sense data is filled with untouched ATA registers.
Signed-off-by: NGwendal Grignou <gwendal@google.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
      f13e2201
  45. 15 5月, 2013 1 次提交
  47. 26 1月, 2013 1 次提交
    • A
      [libata] pm: differentiate system and runtime pm for ata port · a7ff60db
      由 Aaron Lu 提交于 
      We need to do different things for system PM and runtime PM, e.g. we do
not need to enable runtime wake for ZPODD when we are doing system
suspend, etc.

Currently, we use PMSG_SUSPEND for both system suspend and runtime
suspend and PMSG_ON for both system resume and runtime resume. Change
this by using PMSG_AUTO_SUSPEND for runtime suspend and PMSG_AUTO_RESUME
for runtime resume. And since PMSG_ON means no transition, it is changed
to PMSG_RESUME for ata port's system resume.

The ata_acpi_set_state is modified accordingly, and the sata case and
pata case is seperated for easy reading.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      a7ff60db
  49. 22 1月, 2013 2 次提交
    • A
      libata: handle power transition of ODD · 21334205
      由 Aaron Lu 提交于 
      When ata port is runtime suspended, it will check if the ODD attched to
it is a zero power(ZP) capable ODD and if the ZP capable ODD is in zero
power ready state. And if this is not the case, the highest acpi state
will be limited to ACPI_STATE_D3_HOT to avoid powering off the ODD. And
if the ODD can be powered off, runtime wake capability needs to be
enabled and powered_off flag will be set to let resume code knows that
the ODD was in powered off state.

And on resume, before it is powered on, if it was powered off during
suspend, runtime wake capability needs to be disabled. After it is
recovered, the ODD is considered functional, post power on processing
like eject tray if the ODD is drawer type is done, and several ZPODD
related fields will also be reset.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      21334205
    • A
      libata: check zero power ready status for ZPODD · 3dc67440
      由 Aaron Lu 提交于 
      Per the Mount Fuji spec, the ODD is considered zero power ready when:
  - For slot type ODD, no media inside;
  - For tray type ODD, no media inside and tray closed.

The information can be retrieved by either the returned information of
command GET_EVENT_STATUS_NOTIFICATION(the command is used to poll for
media event) or sense code.

The information provided by the media status byte is not accurate, it
is possible that after a new disc is just inserted, the status byte
still returns media not present. So this information can not be used as
the deciding factor, we use sense code to decide if zpready status is
true.

When we first sensed the ODD in the zero power ready state, the
zp_sampled will be set and timestamp will be recoreded. And after ODD
stayed in this state for some pre-defined period, the ODD is considered
as power off ready and the zp_ready flag will be set. The zp_ready flag
serves as the deciding factor other code will use to see if power off is
OK for the ODD.

The Mount Fuji spec suggests a delay should be used here, to avoid the
case user ejects the ODD and then instantly inserts a new one again, so
that we can avoid a power transition. And some ODDs may be slow to place
its head to the home position after disc is ejected, so a delay here is
generally a good idea. And the delay time can be changed via the module
param zpodd_poweroff_delay.

The zero power ready status check is performed in the ata port's runtime
suspend code path, when port is not frozen yet, as we need to issue some
IOs to the ODD.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      3dc67440
  51. 15 1月, 2013 1 次提交