* libata-eh not reporting failed LBA correctly?
@ 2008-04-23 20:02 Mark Lord
2008-04-23 20:23 ` Mark Lord
0 siblings, 1 reply; 2+ messages in thread
From: Mark Lord @ 2008-04-23 20:02 UTC (permalink / raw)
To: Tejun Heo, IDE/ATA development list
Tejun,
I'm now working on (libata-dev#upstream) getting sata_mv to give detailed
error information when a drive reports (for example) a media error.
If I stop sata_mv from freezing the port right away, then libata-eh
correctly runs and issues the READ_LOG_EXT_10H to the drive,
and gets back the correct NCQ error info. So far, so good:
ata31: qc_issue: command=0x60
ata31: mv_err_intr: qc=00000000 err_mask=00000001 err_cause=00000084 freeze_mask=fc1e9ebb freezing port
ata31: qc_issue: command=0x2f
ata31.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata31.00: edma_err_cause=00000084, EDMA self-disable
ata31.00: cmd 60/10:00:08:27:00/00:00:00:00:00/40 tag 0 ncq 8192 in
res 51/40:10:10:27:00/e3:00:00:00:00/00 Emask 0x409 (media error) <F>
ata31.00: status: { DRDY ERR }
ata31.00: error: { UNC }
So there, we see that the drive reported failure on LBA 0x002710 =
sector number 10000 (base10).
This is correct: I corrupted that sector on purpose for the test.
But.. then something peculiar happens:
ata31: qc_issue: command=0xec
ata31: qc_issue: command=0x27
ata31: qc_issue: command=0xef
ata31: qc_issue: command=0xec
ata31: qc_issue: command=0x27
ata31.00: configured for UDMA/133
sd 30:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sd 30:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 00 10
sd 30:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
end_request: I/O error, dev sdb, sector 9992
...
According to SCSI, we either did not report a valid sector number,
or we reported sector 9992 as having the problem. That's not right.
I wonder where we lost that information ?
Looking through libata-eh, I don't see any place that explicitly
sets the result tf.flags field anywhere, other than copying them
from the outgoing READ_LOG_EXT taskfile. Perhaps that's the problem ?
I'll dig some more, but clues would be handy.
Cheers
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: libata-eh not reporting failed LBA correctly?
2008-04-23 20:02 libata-eh not reporting failed LBA correctly? Mark Lord
@ 2008-04-23 20:23 ` Mark Lord
0 siblings, 0 replies; 2+ messages in thread
From: Mark Lord @ 2008-04-23 20:23 UTC (permalink / raw)
To: Tejun Heo, IDE/ATA development list
Mark Lord wrote:
> ...
> Looking through libata-eh, I don't see any place that explicitly
> sets the result tf.flags field anywhere, other than copying them
> from the outgoing READ_LOG_EXT taskfile. Perhaps that's the problem ?
...
Yup, that was it. Patch coming after retest..
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-04-23 20:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-23 20:02 libata-eh not reporting failed LBA correctly? Mark Lord
2008-04-23 20:23 ` Mark Lord
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).