From: "Justin T. Gibbs" <gibbs@scsiguy.com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Fix aic7xxx del_timer_sync() deadlock
Date: Fri, 27 Feb 2004 12:23:58 -0700 [thread overview]
Message-ID: <3462370000.1077909838@aslan.btc.adaptec.com> (raw)
In-Reply-To: <1077906383.2157.98.camel@mulgrave>
> The best fix, I think is to eliminate this timer from the driver. All
> it was doing was providing a time limited queue freeze for the BUSY and
> QUEUE_FULL on no outstanding commands cases. These are handled
> correctly by the mid-layer, so there's no need for the driver do try to
> handle them on it's own.
There are two flaws with your analysis:
1) The mid-layer doesn't correctly handle this situation. The mid-layer
uses blk_plug_device() to implement this behavior rather than
blk_stop_queue(). The leaves the implementation vulnerable to
any code that does a manual unplug (e.g. the SCSI scan code) or a
blk_run_queues() (e.g. MD) which can alter the duration of the delay.
While the host may be able to tune the delay to HZ, the default values
are not. I'm also not sure that leaving the default blk_unplug delay
as 0 gives you a deterministic jiffy long delay before the request
function will be hit again.
2) These drivers both include Domain Validation support. These commands
do not go through the mid-layer at all yet require proper queue full
and busy handling.
--
Justin
next prev parent reply other threads:[~2004-02-27 19:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-27 18:26 [PATCH] Fix aic7xxx del_timer_sync() deadlock James Bottomley
2004-02-27 19:23 ` Justin T. Gibbs [this message]
2004-02-27 19:34 ` James Bottomley
2004-02-27 20:50 ` Justin T. Gibbs
2004-02-28 15:39 ` James Bottomley
2004-02-29 19:26 ` Justin T. Gibbs
2004-02-29 21:10 ` James Bottomley
2004-02-29 22:23 ` Justin T. Gibbs
2004-02-29 21:25 ` James Bottomley
2004-02-28 2:40 ` Jeff Garzik
2004-02-28 9:25 ` Jens Axboe
2004-02-28 23:50 ` Jeff Garzik
2004-02-29 9:13 ` Jens Axboe
2004-02-29 16:21 ` Jeff Garzik
2004-02-29 16:39 ` Jens Axboe
2004-02-29 17:28 ` Jeff Garzik
2004-02-29 17:55 ` Jens Axboe
2004-02-29 18:57 ` Justin T. Gibbs
2004-02-29 19:00 ` Jeff Garzik
2004-02-29 19:28 ` Justin T. Gibbs
2004-02-29 19:37 ` Jeff Garzik
2004-02-29 19:42 ` Justin T. Gibbs
2004-02-29 19:44 ` Jeff Garzik
2004-02-29 20:06 ` Jens Axboe
2004-02-29 20:20 ` Jeff Garzik
2004-02-29 20:27 ` Jens Axboe
2004-02-29 20:28 ` Jeff Garzik
2004-02-29 19:43 ` Jeff Garzik
2004-02-29 20:04 ` 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=3462370000.1077909838@aslan.btc.adaptec.com \
--to=gibbs@scsiguy.com \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@osdl.org \
--cc=linux-scsi@vger.kernel.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