All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Chris Rankin <rankincj@yahoo.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [OOPS] 2.6.11 - NMI lockup with CFQ scheduler
Date: Wed, 6 Apr 2005 14:31:48 +0200	[thread overview]
Message-ID: <20050406123147.GD9417@suse.de> (raw)
In-Reply-To: <20050329122635.GP16636@suse.de>

On Tue, Mar 29 2005, Jens Axboe wrote:
> On Tue, Mar 29 2005, Chris Rankin wrote:
> > >> > I have one IDE hard disc, but I was using a USB memory stick at one
> > > > point. (Notice the usb-storage and vfat modules in my list.) Could
> > > > that be the troublesome SCSI device?
> > 
> > --- Jens Axboe <axboe@suse.de> wrote:
> > > Yes, it probably is. What happens is that you insert the stick and do io
> > > against it, which sets up a process io context for that device. That
> > > context persists until the process exits (or later, if someone still
> > > holds a reference to it), but the queue_lock will be dead when you yank
> > > the usb device.
> > > 
> > > It is quite a serious problem, not just for CFQ. SCSI referencing is
> > > badly broken there.
> > 
> > That would explain why it was nautilus which caused the oops then.
> > Does this mean that the major distros aren't using the CFQ then?
> > Because how else can they be avoiding this oops with USB storage
> > devices?
> 
> CFQ with io contexts is relatively new, only there since 2.6.10 or so.
> On UP, we don't grab the queue lock effetively so the problem isn't seen
> there.
> 
> You can work around this issue by using a different default io scheduler
> at boot time, and then select cfq for your ide hard drive when the
> system has booted with:
> 
> # echo cfq > /sys/block/hda/queue/scheduler
> 
> (substitute hda for any other solid storage device).

Can you check if this work-around solves the problem for you? Thanks!

===== include/linux/blkdev.h 1.162 vs edited =====
--- 1.162/include/linux/blkdev.h	2005-03-29 03:42:37 +02:00
+++ edited/include/linux/blkdev.h	2005-04-06 11:22:44 +02:00
@@ -279,6 +288,7 @@
 typedef int (issue_flush_fn) (request_queue_t *, struct gendisk *, sector_t *);
 typedef int (prepare_flush_fn) (request_queue_t *, struct request *);
 typedef void (end_flush_fn) (request_queue_t *, struct request *);
+typedef void (release_queue_data_fn) (request_queue_t *);
 
 enum blk_queue_state {
 	Queue_down,
@@ -324,6 +334,7 @@
 	issue_flush_fn		*issue_flush_fn;
 	prepare_flush_fn	*prepare_flush_fn;
 	end_flush_fn		*end_flush_fn;
+	release_queue_data_fn	*release_queue_data_fn;
 
 	/*
 	 * Auto-unplugging state
===== drivers/scsi/scsi_sysfs.c 1.72 vs edited =====
--- 1.72/drivers/scsi/scsi_sysfs.c	2005-03-28 07:03:53 +02:00
+++ edited/drivers/scsi/scsi_sysfs.c	2005-04-06 11:24:27 +02:00
@@ -175,9 +175,6 @@
 
 	scsi_target_reap(scsi_target(sdev));
 
-	kfree(sdev->inquiry);
-	kfree(sdev);
-
 	if (parent)
 		put_device(parent);
 }
===== drivers/scsi/scsi_lib.c 1.153 vs edited =====
--- 1.153/drivers/scsi/scsi_lib.c	2005-03-30 21:49:45 +02:00
+++ edited/drivers/scsi/scsi_lib.c	2005-04-06 11:24:32 +02:00
@@ -1420,6 +1420,18 @@
 }
 EXPORT_SYMBOL(scsi_calculate_bounce_limit);
 
+static void scsi_release_queue_data(request_queue_t *q)
+{
+	struct scsi_device *sdev = q->queuedata;
+
+	if (sdev) {
+		kfree(sdev->inquiry);
+		kfree(sdev);
+	}
+
+	q->queuedata = NULL;
+}
+
 struct request_queue *scsi_alloc_queue(struct scsi_device *sdev)
 {
 	struct Scsi_Host *shost = sdev->host;
@@ -1437,6 +1449,8 @@
 	blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
 	blk_queue_segment_boundary(q, shost->dma_boundary);
 	blk_queue_issue_flush_fn(q, scsi_issue_flush_fn);
+
+	q->release_queue_data_fn = scsi_release_queue_data;
 
 	/*
 	 * ordered tags are superior to flush ordering

-- 
Jens Axboe


  reply	other threads:[~2005-04-06 12:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-29 12:22 [OOPS] 2.6.11 - NMI lockup with CFQ scheduler Chris Rankin
2005-03-29 12:26 ` Jens Axboe
2005-04-06 12:31   ` Jens Axboe [this message]
2005-04-06 12:52     ` Arjan van de Ven
2005-04-06 12:55       ` Jens Axboe
2005-04-06 13:38         ` Tejun Heo
2005-04-06 18:01           ` Jens Axboe
2005-04-06 20:32           ` Mike Anderson
  -- strict thread matches above, loose matches on Subject: below --
2005-03-29 11:54 Chris Rankin
2005-03-29 12:03 ` Jens Axboe
2005-04-06 16:27   ` James Bottomley
2005-04-06 17:58     ` Jens Axboe
2005-04-06 18:20       ` James Bottomley
2005-04-06 19:08         ` Jens Axboe
2005-04-06 21:09           ` James Bottomley
2005-04-07  6:49             ` Jens Axboe
2005-04-07 13:18               ` James Bottomley
2005-04-07 13:22                 ` Christoph Hellwig
2005-04-07 13:24                   ` Jens Axboe
2005-04-07 13:30                   ` James Bottomley
2005-04-07 13:32                     ` Jens Axboe
2005-04-07 13:39                       ` James Bottomley
2005-04-07 14:45                         ` Jens Axboe
2005-04-08 13:04                           ` James Bottomley
2005-04-08 13:09                             ` Jens Axboe
2005-04-07 13:24                 ` Jens Axboe
2005-03-27 19:22 Chris Rankin
2005-03-29 11:32 ` 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=20050406123147.GD9417@suse.de \
    --to=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=rankincj@yahoo.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 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.