linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Tejun Heo <htejun@gmail.com>
Cc: Ric Wheeler <ric@emc.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jeff Garzik <jgarzik@pobox.com>,
	linux-ide@vger.kernel.org
Subject: Re: [PATCH 2/2] libata: turn off NCQ if queue depth is adjusted to   1
Date: Sun, 1 Oct 2006 21:55:16 +0200	[thread overview]
Message-ID: <20061001195516.GS5670@kernel.dk> (raw)
In-Reply-To: <451F0BF7.1000200@gmail.com>

On Sun, Oct 01 2006, Tejun Heo wrote:
> Ric Wheeler wrote:
> >Jens Axboe wrote:
> >>On Sat, Sep 30 2006, Alan Cox wrote:
> >>>Ar Sad, 2006-09-30 am 20:04 +0200, ysgrifennodd Jens Axboe:
> >>>>On Sat, Sep 30 2006, Tejun Heo wrote:
> >>>>    
> >>>>>Turn off NCQ if queue depth is adjusted to 1.
> >>>>>      
> >>>>I had thought of that too but discarded it - it would be nicer to have
> >>>>an independent way of turning off NCQ. Say you are debugging a weird 
> >>>>FIS
> >>>>issue, NCQ depth 1 is still a different beast to non-NCQ. I see Jeff
> >>>>already applied the patches, but just thought I'd voice my opinion.
> 
> Yeah, I was putting off this patch for the same reason.  0 depth would 
> have been nice but SCSI midlayer filters such input and libata still 
> doesn't have its own sysfs tree.  So, this was the middle ground.

Don't let that stop you, with good reason it could be changed (or just
allowed for some llds).

> >>>I've got a blacklist for NCQ in my work tree but really we need the
> >>>vendors to help fill it. So far it has some raptors in it but I am sure
> >>>there are more, and I am sure there are cases we should be advising
> >>>newer firmware or just tweaking our queue sizes etc.
> >>
> >>Lots of the older Maxtors are pretty crappy for NCQ, so those too. Queue
> >>size tweaks fixed them for me (as low as 4, and I can't say for sure if
> >>it fixes all crashes).
> 
> I'm gonna update EH such that NCQ is turned off after certain number of 
> errors.  That should at least eventually make the machine usable in such 
> cases, but we definitely need NCQ blacklist.

Depends on what the error is. Some drives completely lock up and need a
hard power cycle (I've seen this), there's no way the EH can recover
that.

> >We have to be careful with the blacklisting - specifically, drive model 
> >is often less critical than the version of the firmware (which gets 
> >updated as people work drives through qualification, etc).
> >Updating drive firmware for end users is pretty rare (and almost all 
> >tools are still DOS based ;-)).
> >
> >Certain drives should default to non-NCQ (based on model), but we should 
> >be able to enable it if the firmware supports it.
> >
> >Most of the newest drives are fine, but we will still need something 
> >like Tejun's fix to be able to turn it off for the odd cases that show 
> >up in certain odd applications, etc.
> 
> Ric, can you press harddisk vendors hard enough such that those model 
> and revision numbers squeeze out of them?

I'm guessing that'll be hard. We can scour the .inf files on the drivers
that enable NCQ on Windows, that's probably a good set of defaults.

-- 
Jens Axboe


  parent reply	other threads:[~2006-10-01 19:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-30 10:44 [PATCH 1/2] libata: cosmetic changes to constants Tejun Heo
2006-09-30 10:45 ` [PATCH 2/2] libata: turn off NCQ if queue depth is adjusted to 1 Tejun Heo
2006-09-30 18:04   ` Jens Axboe
2006-09-30 20:51     ` Alan Cox
2006-09-30 20:26       ` Jens Axboe
2006-10-01  0:17         ` Ric Wheeler
2006-10-01  0:29           ` Tejun Heo
2006-10-01  0:52             ` Ric Wheeler
2006-10-01 12:56               ` Ric Wheeler
2006-12-16 17:19                 ` Jeff Garzik
2006-12-18 10:04                   ` Jens Axboe
2006-10-01 19:55             ` Jens Axboe [this message]
2006-10-04 13:37               ` saeed bishara
2006-10-04 13:37                 ` Jens Axboe
2006-10-05  9:08                   ` Jens Axboe
2006-09-30 11:39 ` [PATCH 1/2] libata: cosmetic changes to constants 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=20061001195516.GS5670@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=htejun@gmail.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=ric@emc.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).