public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Alexey Asemov (Alex/AT)" <alex@alex-at.ru>
To: "Tejun Heo" <tj@kernel.org>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] libata: handle IDE AMNF errors in the EH path
Date: Tue, 15 Jul 2014 01:16:36 +0400	[thread overview]
Message-ID: <op.xi0apyklxbnnkn@violator> (raw)
In-Reply-To: <20140714161010.GE31610@htj.dyndns.org>

Tejun Heo <tj@kernel.org> wrote at Mon, 14 Jul 2014 20:10:10 +0400:

> IIRC AMNF has been deprecated for a very long time now.  The bit isn't
> too likely to get reused given that major updates to ATA spec is
> improbable but I'm still not quite fond of adding handling of a long
> deprecated flag.  Can you please provide a bit more detail?  Which
> device was it?

The hardware is: AMD 6550M-based notebook, WD7500BPVT 2.5" 750G SATA2 hard  
drive. PCI IDs for the controller are 1022:7801 subsys 1025:059d.

I was using linux-based machine to salvage data from failing hard drive,  
and 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. That slowed down salvaging a lot, so the  
patching was done and then everything went smooth.

So I presume AMNF error code is surely not dead yet, and it's better for  
it to be handled. 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).  
Also, there is handling code in libata-scsi.c for 0x01 AMNF error already.  
Not handling it causes excessive retries that can damage failing drivers  
further, and wrong generic error code ("device error") reporting.

  reply	other threads:[~2014-07-14 21:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-12  8:22 [PATCH] libata: handle IDE AMNF errors in the EH path Alexey Asemov
2014-07-14 16:10 ` Tejun Heo
2014-07-14 21:16   ` Alexey Asemov (Alex/AT) [this message]
2014-07-15  6:28   ` [PATCH] 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 Alexey Asemov
2014-07-15 15:16     ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.xi0apyklxbnnkn@violator \
    --to=alex@alex-at.ru \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox