From: Jeff Garzik <jeff@garzik.org>
To: dgilbert@interlog.com
Cc: SCSI development list <linux-scsi@vger.kernel.org>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: libata: SATL error processing: unrecovered read error
Date: Fri, 17 Sep 2010 15:32:28 -0400 [thread overview]
Message-ID: <4C93C24C.1050302@garzik.org> (raw)
In-Reply-To: <4C93C0D5.2090402@interlog.com>
On 09/17/2010 03:26 PM, Douglas Gilbert wrote:
> On 10-09-17 02:31 PM, Jeff Garzik wrote:
>> On 09/05/2010 11:57 AM, Douglas Gilbert wrote:
>>> While looking at an eSATA connected external disk with
>>> a medium error, this sense data appeared:
>>>
>>> READ cdb: 28 00 96 4a 7a d1 00 00 01 00
>>> duration=2816 ms
>>> READ: Descriptor format, current; Sense key: Medium Error
>>> Additional sense: Unrecovered read error - auto reallocate failed
>>> Descriptor type: Information
>>> 0x00000000964a7ad1
>>> Raw sense data (in hex):
>>> 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
>>> 96 4a 7a d1
>>>
>>> That is pretty close to what I was expecting to see. If anything
>>> there is too much information. That "Unrecovered read error -
>>> auto reallocate failed" [asc/asq: 11h/04h] should just be
>>> "Unrecovered read error" [asc/asq: 11h/0h]. See sat2r09.pdf table
>>> 105 or sat3r00.pdf table 105.
>>
>> If any auto-reallocate occurred on the drive's part, it definitely
>> failed at that point. And auto-reallocate is a possibility.
>>
>> 11h/04h seems to more accurately describe the situation.
>
> Usually if you are implementing a SCSI device (lu) there
> is some latitude in asc/asq codes. However for a SAT layer
> they state exactly how to translate ATA errors.
>
> There is one published SAT standard (ANSI INCITS 431-2007)
> and there will soon be another one (SAT-2). The compliant
> response is asc/asq: 11h/0h since in t10 documents additional
> sense matches by string which is shown in upper case.
Fair enough. Wanna write a patch? :)
> BTW I never understood what asc/asq 11h/04h was about,
> auto-reallocate is something that should be attempted
> on a _recovered_ read error. And that in turn might fail
> if the disk had run out of spare blocks. So in a contorted
> sort of way, perhaps that is what "Unrecovered read error -
> auto reallocate failed" means!? If so, you are most
> likely incorrect on that count as well.
The ATA disk hits an unrecovered read error, which by virtue of
operation implies auto reallocate failed. What's going on inside seems
to match the error text quite closely.
Jeff
prev parent reply other threads:[~2010-09-17 19:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-05 15:57 libata: SATL error processing: unrecovered read error Douglas Gilbert
2010-09-17 18:31 ` Jeff Garzik
2010-09-17 19:26 ` Douglas Gilbert
2010-09-17 19:32 ` Jeff Garzik [this message]
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=4C93C24C.1050302@garzik.org \
--to=jeff@garzik.org \
--cc=dgilbert@interlog.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.