All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Ed Lin <ed.lin@promise.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	Andrew Morton <akpm@linux-foundation.org>, jeff <jeff@garzik.org>,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: stex driver panic in kernel 2.6.23
Date: Mon, 29 Oct 2007 21:22:06 +0100	[thread overview]
Message-ID: <20071029202206.GE7499@kernel.dk> (raw)
In-Reply-To: <NONAMEWEXxt5BBBVhye0000037a@nonamew.ptu.promise.com>

On Mon, Oct 29 2007, Ed Lin wrote:
> 
> >On Wed, Oct 24 2007, James Bottomley wrote:
> >> On Wed, 2007-10-24 at 12:17 -0700, Andrew Morton wrote:
> >> > On Wed, 24 Oct 2007 11:59:30 -0700 "Ed Lin" <ed.lin@promise.com> wrote:
> >> > 
> >> > > The shared tag issue was not fixed yet. Kernel panic
> >> > > happened while running I/O test in kernel 2.6.23
> >> > > (information attached). After applying the patch I posted
> >> > > (or the version James modified), panic disappeared.
> >> > > Switch back to standard kernel, panic again.
> >> > 
> >> > Did either of those patches get merged in 2.6.24-rc1?
> >> 
> >> No ... Jens did one instead (commit
> >> f3da54ba140c6427fa4a32913e1bf406f41b5dda), which now looks like it might
> >> not have fixed the issue.
> >
> >I think there's one more bug there, for shared maps. For the locking to
> >work, only the tag map and tag bit map may be shared (incidentally, I
> >was just explaining this to Nick yesterday, but I apparently didn't
> >review the code well enough myself). But we also share the busy list!
> >The busy_list must be queue private, or we need a block_queue_tag
> >covering lock as well.
> >
> >So we have to move the busy_list to the queue. This'll work fine, and
> >it'll actually also fix a problem with blk_queue_invalidate_tags() which
> >will invalidate tags across all shared queues. This is a bit confusing,
> >the low level driver should call it for each queue seperately since
> >otherwise you cannot kill tags on just a single queue for eg a hard
> >drive that stops responding. Since the function has no callers
> >currently, it's not an issue.
> >
> >Please test.
> >
> 
> With this patch the stex driver passed I/O test. So maybe this problem is
> fixed finally. Thanks. Please apply.

I do hope so... The patch is in Linus upstream tree now, will send a
variant for the stable series as well.

-- 
Jens Axboe


  reply	other threads:[~2007-10-29 20:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 17:46 stex driver panic in kernel 2.6.23 Ed Lin
2007-10-29 20:22 ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-10-24 18:59 Ed Lin
2007-10-24 19:15 ` James Bottomley
2007-10-24 19:17   ` James Bottomley
2007-10-24 19:17 ` Andrew Morton
2007-10-24 19:29   ` James Bottomley
2007-10-25  8:11     ` 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=20071029202206.GE7499@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=akpm@linux-foundation.org \
    --cc=ed.lin@promise.com \
    --cc=jeff@garzik.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 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.