2.6.6-mm4 and failing SATA drive

[R. J. Wysocki]

Hi,

Seemingly, I'm having a problem with one of my SATA drives.  It is connected 
via a SII3114 chip (on-board) and worked just fine until a couple of hours 
ago when I tried to scp ~700 MB of data to it.  Then, the process handling 
that request hung in a kernel code (ie. became unkillable with -9) and I got 
this in the log:

May 21 22:26:31 chimera kernel: ata1: DMA timeout, stat 0x61
May 21 22:26:31 chimera kernel: ATA: abnormal status 0xD8 on port 
0xFFFFFF0000655C87
May 21 22:26:31 chimera kernel: scsi1: ERROR on channel 0, id 0, lun 0, CDB: 
Write (10) 00 03 2a 14 17 00 02 58 00 
May 21 22:26:31 chimera kernel: Current sdc: sense key Medium Error
May 21 22:26:31 chimera kernel: Additional sense: Write error - auto 
reallocation failed
May 21 22:26:31 chimera kernel: end_request: I/O error, dev sdc, sector 
53089303
May 21 22:26:31 chimera kernel: ATA: abnormal status 0xD8 on port 
0xFFFFFF0000655C87
May 21 22:26:31 chimera last message repeated 2 times

So, there probably is a hardware problem, but:

1) can you, please, tell me what _exactly_ this means,

2) after it had happened I was unable to do anything with the partition in 
question and I couldn't reboot the machine softly (SysRq+S did not work too) 
so I had to use the red button to get around it (_bad_ thing, IMO).

Well, I would like the kernel to behave more "nicely" in such cases, if 
possible.  In other words, there should be a way to get around a failing 
piece of equipment without rebooting the machine (I know it may be impossible 
but this is not the case, AFAICS).

The kernel is a 2.6.6-mm4 and my box is a dual Opteron.

If you need any more information, just let me know.

Yours,
RJW

-- 
Rafael J. Wysocki,
SiSK
[tel. (+48) 605 053 693]
----------------------------
For a successful technology, reality must take precedence over public 
relations, for nature cannot be fooled.
					-- Richard P. Feynman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/