From: Mike Anderson <andmike@linux.vnet.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
Alexander Beregalov <a.beregalov@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-next@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
linux-scsi@vger.kernel.org, David Miller <davem@davemloft.net>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: next-20081119: general protection fault: get_next_timer_interrupt()
Date: Mon, 24 Nov 2008 13:35:17 -0800 [thread overview]
Message-ID: <20081124213517.GA25898@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.0811242018370.3235@localhost.localdomain>
Thomas Gleixner <tglx@linutronix.de> wrote:
> > Well, not sure. Most likely candidate is the new block timer code.
> > What seems to be happening is that the queue is being released with
> > either an outstanding request (refcounting problem) or ticking timer
> > with no work (block timer problem). The way scanning works is that we
> > create a request queue for each device we probe and then delete it again
> > if nothing appears after the bus settle time. The argument against
> > this is that it should show up on every scanned bus. However, these are
> > getting rarer; I was just about to write that I hadn't seen it when I
> > remembered that all my SCSI testing systems are currently running
> > hotplug reporting busses (i.e. don't do scanning). However,
> > fortunately, I've also booted voyager recently which does use parallel
> > SCSI and doesn't see this either, so it could also be megaraid_sas
> > specific.
>
> Yeah, block could it be as well. Jens, Mike ?
I added a comment to bug 12020 on Thursday about a few other systems that
where seeing the signature shown in bug 12020. It appeared from debug that
there where a few paths that where adding timers for requests that where
not expected.
http://bugzilla.kernel.org/show_bug.cgi?id=12020
It would be good to know if the debug patch below effects your problem as while.
If it does we need to investigated a solution to resolve not adding a
timer for these requests.
-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com
blk: blk_add_timer debug patch
[DEBUG] Debug only patch.
Debug patch to blk_add_timer to not start timer for request that do not
have the REQ_STARTED flag set.
Signed-off-by: Mike Anderson <andmike@linux.vnet.ibm.com>
---
block/blk-timeout.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/block/blk-timeout.c b/block/blk-timeout.c
index 69185ea..4389391 100644
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -177,6 +177,9 @@ void blk_add_timer(struct request *req)
BUG_ON(!list_empty(&req->timeout_list));
BUG_ON(test_bit(REQ_ATOM_COMPLETE, &req->atomic_flags));
+ if (!(req->cmd_flags & REQ_STARTED))
+ return;
+
if (req->timeout)
req->deadline = jiffies + req->timeout;
else {
--
1.5.6.5
next prev parent reply other threads:[~2008-11-24 21:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-19 15:14 next-20081119: general protection fault: get_next_timer_interrupt() Alexander Beregalov
2008-11-19 21:14 ` Thomas Gleixner
2008-11-21 10:50 ` Alexander Beregalov
2008-11-24 17:43 ` Thomas Gleixner
2008-11-24 19:15 ` James Bottomley
2008-11-24 19:31 ` Thomas Gleixner
2008-11-24 21:35 ` Mike Anderson [this message]
2008-11-24 22:33 ` Thomas Gleixner
2008-11-24 23:42 ` malahal
2008-11-25 0:09 ` malahal
2008-11-25 0:57 ` Stephen Rothwell
2008-11-25 2:08 ` malahal
2008-11-25 8:51 ` Jens Axboe
2008-11-25 16:59 ` malahal
2008-11-25 17:14 ` Alexander Beregalov
2008-11-25 17:14 ` Alexander Beregalov
2008-11-25 17:43 ` Jens Axboe
2008-11-25 17:14 ` Alexander Beregalov
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=20081124213517.GA25898@linux.vnet.ibm.com \
--to=andmike@linux.vnet.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=a.beregalov@gmail.com \
--cc=davem@davemloft.net \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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.