This message is from the T13 list server.
For UDMA "interface" CRC error, you should get status=51h and error=84h. UNC bit would not be set since the data is correct on the media, and the error occurred during transfer across the cable. Now is it possible to get an error value of C4h? I'd think that the UNC error would take precedence and trigger before the ICRC. MKE. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pat LaVarre Sent: Monday, December 01, 2003 1:20 PM To: [EMAIL PROTECTED] Subject: [t13] udma crc innocent This message is from the T13 list server. Q: Can a 'status=0x51' 'error=0x40' trouble mean a udma crc failed? A: Not for a compliant device. I reach that conclusion as follows, anyone want to comment? Pat LaVarre --- Linux /var/log/messages sometimes tells me: Dec 1 13:45:57 patrh9 kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } Dec 1 13:45:57 patrh9 kernel: hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=8253822, sector=8253704 Dec 1 13:45:57 patrh9 kernel: end_request: I/O error, dev hda, sector 8253704 People in real life keep trying to tell me with hdd failure isn't normal, e.g. here I should suspect my cabling. So I ask: Can a 'status=0x51' 'error=0x40' trouble mean a udma crc failed? As you can see, I'm testing our (t13) tolerance of ignorant questions. Personally I know nearly nothing of ATA and of Linux. Glancing over 2000 Feb d1321r3.pdf 6.6. "Ultra DMA feature set" doesn't tell me how ATA HDD report UDMA CRC failed. Possibly 8.45 op xCA "WRITE DMA", 8.45.6 "Error Outputs" says t13 requires x1F1 Error & x80 ICRC set for UDMA CRC ... So I'm guessing x40 means trouble other than UDMA CRC. If I repeatedly read the whole HDD, the read failures don't all repeat consistently, but often I do see the same lba's mentioned again (provided I `blockdev --flushbufs /dev/hda` to clear the stale read cache). ---
