From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Lord Subject: Re: LibPATA code issues / 2.6.15.4 Date: Mon, 27 Feb 2006 16:34:06 -0500 Message-ID: <4403704E.4090109@rtr.ca> References: <43F2050B.8020006@dgreaves.com> <200602141300.37118.lkml@rtr.ca> <440040B4.8030808@dgreaves.com> <440083B4.3030307@rtr.ca> <4400A1BF.7020109@rtr.ca> <4400B439.8050202@dgreaves.com> <4401122A.3010908@rtr.ca> <44017B4B.3030900@dgreaves.com> <4401B560.40702@rtr.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from rtr.ca ([64.26.128.89]:1695 "EHLO mail.rtr.ca") by vger.kernel.org with ESMTP id S1751254AbWB0Vec (ORCPT ); Mon, 27 Feb 2006 16:34:32 -0500 In-Reply-To: <4401B560.40702@rtr.ca> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Jeff Garzik Cc: David Greaves , Justin Piszcz , linux-kernel@vger.kernel.org, IDE/ATA development list , albertcc@tw.ibm.com, axboe@suse.de, htejun@gmail.com, Linus Torvalds Mark Lord wrote: >> Mark Lord wrote: >> >>>> 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 > .. >>> 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. .. hold off on 2.6.16 because of this or not? > > Well, no doubt whatsoever about it being a "regression", > since the FUA code is *new* in 2.6.16 (not present in 2.6.15). > > The FUA code should either get fixed, or removed from 2.6.16. Actually, now that I've done a little more digging, this FUA stuff is inherently dangerous as implemented. A least a few SATA controllers including pipelines and whatnot that rely upon recognizing the (S)ATA opcodes being using. And I sincerely doubt that any of those will recognize the very newish (and aptly named..) FUA opcodes. These may be unsafe in general, unless we tag controllers as FUA-capable and NON-FUA-capable, in addition to tagging the drives. :/