From: Mike Anderson <andmike@linux.vnet.ibm.com>
To: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Cc: Tejun Heo <tj@kernel.org>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Mike Christie <michaelc@cs.wisc.edu>,
Christoph Hellwig <hch@lst.de>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Andrew Morton <akpm@osdl.org>,
Alan Stern <stern@rowland.harvard.edu>,
Hannes Reinecke <hare@suse.de>,
Boaz Harrosh <bharrosh@panasas.com>,
Jens Axboe <jens.axboe@oracle.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Linux-iSCSI.org Target Dev"
<linux-iscsi-target-dev@googlegroups.com>
Subject: Re: Changes to Linux/SCSI target mode infrastructure for v2.6.28
Date: Mon, 1 Dec 2008 22:40:36 -0800 [thread overview]
Message-ID: <20081202064036.GC14025@linux.vnet.ibm.com> (raw)
In-Reply-To: <1228194335.6229.17.camel@haakon2.linux-iscsi.org>
Nicholas A. Bellinger <nab@linux-iscsi.org> wrote:
> On Tue, 2008-12-02 at 13:18 +0900, Tejun Heo wrote:
> >
> > >>> The other one is a BUG_ON in blk/blk-timeout.c:177 in blk_add_timeout()
> > >>> that happens after a few hundred MB of READ_10 traffic, which also
> > >>> appears to pass through elv_dequeue_request() at some point:
> > >>>
> > >>> http://linux-iscsi.org/builds/user/nab/2.6.28-rc6-oops-2.png
> > >>> http://linux-iscsi.org/builds/user/nab/2.6.28-rc6-oops-4.png
> >
> > Hmmm... this means blk_add_timer() is being called after the request
> > is already completed.
or is it possible since elv_dequeue_request BUG_ON check of queuelist did
not trigger a request is on the queuelist with a timeout_list not empty.
It would be interesting for a debug run to change the
"BUG_ON(!list_empty(&req->timeout_list))" in blk_add_timer to print out
the cmd_flags plus req->atomic_flags and also add a
"BUG_ON(!list_empty(&rq->timeout_list))" to elv_insert to ensure a request
is never added to the queuelist with a timeout_list not empty.
> All the problem discovered till now have to do
> > with timeout going off without the low level driver knowing about the
> > request. I don't have much idea and it'll probably be best to trace
> > what's going on using blktrace or printks.
>
> <nod>, OK.
>
> > Maybe this is caused by
> > list corruption as with the first issue or request completion races
> > with requeueing?
>
> Hrmm, yeah, perhaps the use of scsi_req_map_sg() (which obviously still
> has struct bio behind it) is causing the breakage.. I will wait for
> Tomo, Boaz and co to have a look at the original patch to
> lio-core-2.6.git/drivers/lio-core/target_core_pscsi.c and see if I am
> missing something obvious.
>
> Also, with the previous patch to drivers/scsi/scsi_lib.c(), I am able to
> move a few GB of bulk I/O and not hit the BUG_ON in
> blk/blk-timeout.c:177 in blk_add_timeout() mentioned above when feeding
> struct request into struct scsi_device->request_queue with
> blk_execute_rq_nowait() with use_sg > 0 CDBs. However, I am still
> running into another reproducable BUG_ON in
> block/cfq-iosched.c:cfq_find_next_rq() after extended bulk I/O tests.
>
-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com
next prev parent reply other threads:[~2008-12-02 6:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-02 1:52 Changes to Linux/SCSI target mode infrastructure for v2.6.28 Nicholas A. Bellinger
2008-12-02 1:52 ` Nicholas A. Bellinger
2008-12-02 2:04 ` Nicholas A. Bellinger
2008-12-02 3:10 ` Nicholas A. Bellinger
2008-12-02 3:25 ` Nicholas A. Bellinger
2008-12-02 3:43 ` Tejun Heo
2008-12-02 4:18 ` Tejun Heo
2008-12-02 5:05 ` Nicholas A. Bellinger
2008-12-02 6:40 ` Mike Anderson [this message]
2008-12-02 7:49 ` Nicholas A. Bellinger
2008-12-02 8:30 ` Nicholas A. Bellinger
2008-12-02 8:35 ` Nicholas A. Bellinger
2008-12-02 9:13 ` Mike Anderson
2008-12-02 23:18 ` Nicholas A. Bellinger
2008-12-03 0:47 ` Nicholas A. Bellinger
2008-12-02 8:39 ` Boaz Harrosh
2008-12-02 10:34 ` Nicholas A. Bellinger
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=20081202064036.GC14025@linux.vnet.ibm.com \
--to=andmike@linux.vnet.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@osdl.org \
--cc=bharrosh@panasas.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=jens.axboe@oracle.com \
--cc=linux-iscsi-target-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=nab@linux-iscsi.org \
--cc=stern@rowland.harvard.edu \
--cc=tj@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 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.