All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Alan Cox <alan@redhat.com>
Cc: torvalds@osdl.org, linux-kernel@vger.kernel.org, axboe@suse.dk
Subject: Re: Nasty IDE crasher in 2.6.9rc1
Date: Fri, 3 Sep 2004 16:50:54 +0200	[thread overview]
Message-ID: <20040903145054.GQ1631@suse.de> (raw)
In-Reply-To: <20040831142335.GA15841@devserv.devel.redhat.com>


(suse.dk is not related to suse.de and it helpfully eats all messages
sent to unknown users. not so great :(

On Tue, Aug 31 2004, Alan Cox wrote:
> You never never issue unknown commands to drives. Thats how Mandrake destroyed 
> CD-ROM drives. I knew this was in -mm and supposed to be getting sorted I was
> somewhat horrified to find it in 2.6.9rc1.
> 
> This patch crashes two of my CF cards (one so badly you have to reformat it
> to get it back) and anything attached to an IT8212 controller. The correct
> fix is to do what the standard actually says and always check for cache
> flush. Contrary to the comment in the patch drives do report this correctly
> its just that some of them nop unknown commands.
> 
> Please fix this patch segment for rc2, its not just wrong, its dangerous.

Ugh, that's bad. I agree with the change, thanks. Linus passed it on.

> Another problem with barrier is that it can take several minutes worst case
> for the command to complete on a large modern drive (timings c/o friendly
> ide drive engineer). That causes two problems I've pointed out to Jens that
> we need to fix before barriers are IMHO production grade

Can you pass me his results?

> 1.	Anything based on fairness and latency is screwed. Throughput 
> 	apparently is up so it makes sense for some users, and probably
> 	for others we should write cache off as Jens suggested.

Yes, it's a tradeoff. The user can decide himself what is most
important. It all depends on the work load, of course.

> 2.	The timeouts on the command issue appear to be too small, and
> 	we will time out and reset the drive in loaded situations. 

You don't seem to address that in your patch?

> Thankfully next generation ATA has both cache bypass writes and tagging.

But the tagging still isn't useful for this. Have they added
WIN_WRITE_DMA_EXT_QUEUED_FUA?

-- 
Jens Axboe


  reply	other threads:[~2004-09-03 14:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 14:23 Nasty IDE crasher in 2.6.9rc1 Alan Cox
2004-09-03 14:50 ` Jens Axboe [this message]
2004-09-03 13:59   ` Alan Cox
2004-09-03 15:19     ` Jens Axboe

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=20040903145054.GQ1631@suse.de \
    --to=axboe@suse.de \
    --cc=alan@redhat.com \
    --cc=axboe@suse.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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 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.