public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@redhat.com>
To: torvalds@osdl.org, linux-kernel@vger.kernel.org, axboe@suse.dk
Subject: Nasty IDE crasher in 2.6.9rc1
Date: Tue, 31 Aug 2004 10:23:35 -0400	[thread overview]
Message-ID: <20040831142335.GA15841@devserv.devel.redhat.com> (raw)

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.

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

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.

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

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

diff -Nru a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
--- a/drivers/ide/ide-disk.c	2004-08-24 00:04:06 -07:00
+++ b/drivers/ide/ide-disk.c	2004-08-24 00:04:06 -07:00
@@ -1543,6 +1608,27 @@
 		drive->wcache = 1;
 
 	write_cache(drive, 1);
+
+	/*
+	 * decide if we can sanely support flushes and barriers on
+	 * this drive. unfortunately not all drives advertise FLUSH_CACHE
+	 * support even if they support it. So assume FLUSH_CACHE is there
+	 * always. LBA48 drives are newer, so expect it to flag support
+	 * properly. We can safely support FLUSH_CACHE on lba48, if capacity
+	 * doesn't exceed lba28
+	 */
+	barrier = 1;
+	if (drive->addressing == 1) {
+		if (capacity > (1ULL << 28) && !ide_id_has_flush_cache_ext(id))
+			barrier = 0;
+	}
+
+	printk("%s: cache flushes %ssupported\n",
+		drive->name, barrier ? "" : "not ");
+	if (barrier) {
+		blk_queue_ordered(drive->queue, 1);
+		blk_queue_issue_flush_fn(drive->queue, idedisk_issue_flush);
+	}
 }
 
 static void ide_cacheflush_p(ide_drive_t *drive)

             reply	other threads:[~2004-08-31 14:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 14:23 Alan Cox [this message]
2004-09-03 14:50 ` Nasty IDE crasher in 2.6.9rc1 Jens Axboe
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=20040831142335.GA15841@devserv.devel.redhat.com \
    --to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox