Recently I encountered a kernel message:ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0ata3.00: irq_stat 0x40000008ata3.00: failed command: READ FPDMA QUEUEData3.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 cmdata3.00: SB600 AHCI: limiting to 255 sectors per cmdata3.00: configured for UDMA/133sd 2:0:0:0: [sda] Unhandled sense codesd 2:0:0:0: [sda]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSEsd 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 failedsd 2:0:0:0: [sda] CDB: Read(10): 28 00 13 78 b2 98 00 00 08 00end_request: I/O error, dev sda, sector 326677146ata3: EH completeI 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?
Trapping READ FPDMA QUEUED
linux;kernel;hard disk;storage