All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-ide@vger.kernel.org, edmudama@gmail.com,
	Nicolas.Mailhot@LaPoste.net
Subject: Re: libata FUA revisited
Date: Mon, 12 Feb 2007 18:23:15 -0600	[thread overview]
Message-ID: <45D104F3.7040602@shaw.ca> (raw)
In-Reply-To: <fa.Q/csgyCHkAsD84yi+bN78H1WNNM@ifi.uio.no>

Tejun Heo wrote:
>> -Add a new port flag ATA_FLAG_NO_FUA to indicate that a controller 
>> can't handle FUA commands, and add that flag to sata_sil. Force FUA 
>> off on any drive connected to a controller with this bit set.
>>
>> There was some talk that sata_mv might have this problem, but I 
>> believe the conclusion was that it didn't. The only controllers that 
>> would are ones that actually try to interpret the ATA command codes 
>> and don't know about WRITE DMA FUA.
> 
> I think it would be better to add ATA_FLAG_FUA instead of ATA_FLAG_NO_FUA.

I'm not sure about that, it appears that the number of controllers that 
have problems is much lower than the number that don't, so this would 
just need to be added to almost every driver. Especially since the 
non-NCQ FUA which was problematic on SiI in the past isn't being 
switched on by default.

>> -Change the fua module option to control FUA enable/disable to have a 
>> third value, "enable for NCQ-supporting drives only", which would 
>> become the new default. That case seems less likely to cause problems 
>> since FUA on NCQ is just another bit in the command whereas FUA on 
>> non-NCQ is an entirely different, potentially unsupported command.
> 
> Not enabling FUA doesn't result in huge performance hit.  I'm not sure 
> whether we should go such far.  Just supporting FUA on known good 
> controllers sounds good enough to me.

On the NCQ side, I think it's pretty safe to assume that all controllers 
will handle it. Obviously I've verified it with sata_nv (at least that 
it doesn't blow up obviously), and the other two NCQ drivers we have, 
ahci and sata_sil24 just feed raw FIS data into the controller so there 
should be no issue with not supporting it.

Assuming that we leave FUA off by default for non-NCQ for the 
foreseeable future, is there really much concern here?

> 
>> Any comments?
>>
>> As an aside, I came across a comment that the Silicon Image Windows 
>> drivers for NCQ-supporting controllers have some blacklist entries for 
>> drives with broken NCQ in their .inf files. We only seem to have one 
>> in the libata NCQ blacklist, we may want to add some more of these. 
>> The ones in the current SiI3124 and 3132 drivers' .inf files for 
>> "DisableSataQueueing" appear to be:
>>
>> Model                Firmware
>> Maxtor 7B250S0            BANC1B70
>> HTS541060G9SA00            MB3OC60D
>> HTS541080G9SA00            MB4OC60D
>> HTS541010G9SA00            MBZOC60D
>>
>> (the latter 3 being Hitachi Travelstar drives)
> 
> Yeah, I don't think we need to be too careful about blacklisting NCQ 
> considering the sorry state of many early NCQ firmwares.  Please submit 
> a patch.  It would be nice if you add a comment why the drives are added 
> for documentation.

Will do shortly. Eric, do you have any info on the blacklisting of that 
Maxtor 7B250S0 drive? I would hope that Silicon Image would have a good 
reason for blacklisting that one..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


  parent reply	other threads:[~2007-02-13  0:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.S80SRyQbD/hm4SxliPUKU88BaCo@ifi.uio.no>
2007-02-12  5:47 ` Robert Hancock
     [not found] ` <fa.Q/csgyCHkAsD84yi+bN78H1WNNM@ifi.uio.no>
2007-02-13  0:23   ` Robert Hancock [this message]
2007-02-13 15:20     ` Tejun Heo
2007-02-14  0:07       ` Robert Hancock
2007-02-14  0:50         ` Tejun Heo
2007-02-15 18:00           ` Jens Axboe
2007-02-19 19:46             ` Robert Hancock
2007-02-21  8:37               ` Tejun Heo
2007-02-21  8:46                 ` Jens Axboe
2007-02-21  8:57                   ` Tejun Heo
2007-02-21  9:01                     ` Jens Axboe
2007-02-22 22:44                     ` Ric Wheeler
2007-02-22 22:40                   ` Ric Wheeler
2007-02-21 14:06                 ` Robert Hancock
2007-02-22 22:34                 ` Ric Wheeler
2007-02-23  0:04                   ` Robert Hancock
2007-02-21  8:44               ` Jens Axboe
2007-02-12  3:25 Robert Hancock
2007-02-12  8:31 ` Tejun Heo
2007-02-16 18:14   ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45D104F3.7040602@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=Nicolas.Mailhot@LaPoste.net \
    --cc=edmudama@gmail.com \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: libata FUA revisited' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.