Re: LibPATA code issues / 2.6.15.4

[Mark Lord <lkml@rtr.ca>]

David Greaves wrote:
>
> Linux haze 2.6.16-rc4patched #1 PREEMPT Sat Feb 25 19:29:11 UTC 2006
> i686 GNU/Linux
> 
> ata2: status=0x51 { DriveReady SeekComplete Error }
> ata2: error=0x04 { DriveStatusError }
> ata2: no sense translation for op=0x2a cmd=0x3d status: 0x51
> ata2: status=0x51 { DriveReady SeekComplete Error }
> ata2: no sense translation for op=0x2a cmd=0x3d status: 0x51
> ata2: status=0x51 { DriveReady SeekComplete Error }
> ata2: no sense translation for op=0x2a cmd=0x3d status: 0x51
> ata2: status=0x51 { DriveReady SeekComplete Error }
> ata2: no sense translation for op=0x2a cmd=0x3d status: 0x51
> ata2: status=0x51 { DriveReady SeekComplete Error }
> sd 1:0:0:0: SCSI error: return code = 0x8000002
> sdb: Current: sense key: Medium Error
>     Additional sense: Unrecovered read error - auto reallocate failed
> end_request: I/O error, dev sdb, sector 398283329
> raid1: Disk failure on sdb2, disabling device.
>         Operation continuing on 1 devices

Oh good, *now* we've gotten somewhere!!

Albert / Jens / Jeff:

The command failing above is SCSI WRITE_10, which is being
translated into ATA_CMD_WRITE_FUA_EXT by libata.

This command fails -- unrecognized by the drive in question.
But libata reports it (most incorrectly) as a "medium error",
and the drive is taken out of service from its RAID.

Bad, bad, and worse.

Libata should really recover from this, by recognizing that
the command was rejected, and replacing it with a simple
WRITE_EXT instead.  Possibly followed by FLUSH_CACHE.

So.. I've forgotten who put FUA into libata, but hopefully
it's one of the folks on the CC: list, and that nice person
can now generate a patch to fix this bug somehow.

Cheers