Skip to contentSkip to conversation

libata: SATL error processing: unrecovered read error

DISCUSSION Douglas Gilbert 2 participants 4 messages Sep 5, 2010 – Sep 17, 2010

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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.

The problem seems to be in libata's SATL code in the sense_table[] in ata_to_sense_error() in libata-scsi.c . Looks like some other entries in that sense_table need adjusting as well to align them to SAT's table 105.

Also it is good to have a reference comment as sense_data[] does in lk 2.6.35:
/* Based on the 3ware driver translation table */

but this would be better (if it did comply):
/* Based on table 105 in SAT-2 rev 9 */

Doug Gilbert

#1 lore raw
Quoted 13 lines · Douglas Gilbert

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

Quoted 5 lines

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.

Jeff

#2 lore raw
Quoted 20 lines · Jeff Garzik
Quoted 13 lines · Douglas Gilbert

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

Quoted 5 lines

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.

Quoted 4 lines

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.

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.

Doug Gilbert

#3 lore raw
Quoted 26 lines · Douglas Gilbert
Quoted 20 lines · Jeff Garzik
Quoted 13 lines · Douglas Gilbert

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

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 8 lines

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? :)

Quoted 7 lines

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