Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Recently I encountered a kernel message:

ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
ata3.00: irq_stat 0x40000008
ata3.00: failed command: READ FPDMA QUEUED
ata3.00: cmd 60/08:00:98:b2:78/00:00:13:00:00/40 tag 0 ncq 4096 in
         res 41/40:08:9a:b2:78/00:00:13:00:00/00 Emask 0x409 (media error) <F>
ata3.00: status: { DRDY ERR }
ata3.00: error: { UNC }
ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
ata3.00: SB600 AHCI: limiting to 255 sectors per cmd
ata3.00: configured for UDMA/133
sd 2:0:0:0: [sda] Unhandled sense code
sd 2:0:0:0: [sda]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 2:0:0:0: [sda]  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 
        13 78 b2 9a 
sd 2:0:0:0: [sda]  Add. Sense: Unrecovered read error - auto reallocate failed
sd 2:0:0:0: [sda] CDB: Read(10): 28 00 13 78 b2 98 00 00 08 00
end_request: I/O error, dev sda, sector 326677146
ata3: EH complete

I managed to correct the error and wrote a detailed description of the convoluted process I used to repair the disk. Then got too lazy to post it ( guess I will this weekend ).

What I would like to do now is create some programs for automating the process. To do this I need to "trap the kernel error".

By trap I mean: 1) Terminate the system call that is causing the error. I notice that often times errors like this will cause the hd to hang, that is ignore requests from other system command calls until this process has run its course. Often times causing the other calls to return errors. With a diagnostic program this will cause the wrong action to be identified as the culprit.

2) Send a signal of some sort to the calling process to let it know that it is the culprit.

Suggestions?

share|improve this question
add comment

1 Answer

The program that "caused" it (really, its caused by bad hardware, it'd be more appropriate to say "the program that was the victim of it") may not even exist anymore.

E.g., send off a write, and then exit. The write will sit in the kernel buffers until the kernel performs writeback. At which point an I/O error may occur.

When the program does still exist, it will already be told of the error. For example, read will set errno to EIO. (This error may also come back from write, fsync, fdatasync, or even close.)

The reason it takes forever has nothing to do with the kernel, it's entirely the drive. The drive spends a while retrying the read to see if it can make sense of the corrupted sector. If you don't want this (e.g., because you're running on RAID, and will just reschedule the sector to the disk's mirror) you can try changing the SCT Error Recovery Control settings using smartctl. Beware that many non-enterprise disks do not support this.

Except in the case of RAID (or similar), there is no way to automatically fix it. The data has been lost. The kernel can't fix that.

If you're running Linux software RAID (mdraid), with even a half-recent kernel, mdraid will automatically fix it by reading the errored sector from the mirror, then writing the correct sector back to the drive with a read error.

If you're getting this on a write instead of a read, then replace the drive.

(BTW: READ FPDMA QUEUED is not an error. Its just the (S)ATA command that failed. "Medium Error" is the error.)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.