[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160512071207.GC25134@c203.arch.suse.de>
Date: Thu, 12 May 2016 09:12:08 +0200
From: Johannes Thumshirn <jthumshirn@...e.de>
To: Keith Busch <keith.busch@...el.com>
Cc: Wenbo Wang <mail_weber_wang@....com>, axboe@...com,
stable@...r.kernel.org, wenwei.tao@...blaze.com,
linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
Wenbo Wang <wenbo.wang@...blaze.com>
Subject: Re: [PATH v2] NVMe: init nvme queue before enabling irq
On Wed, May 11, 2016 at 03:16:33PM -0400, Keith Busch wrote:
> On Wed, May 11, 2016 at 11:25:16AM +0200, Johannes Thumshirn wrote:
> > What ever happened to this patch?
> > I can easily reproduce the bug using
> > while [ true ]; do rmmod nvme nvme_core; modprobe nvme; done
>
> This patch was supposed to fix using a doorbell between resets when the
> driver had BAR0 unmapped. We don't ever unmap the bar anymore, so this
> patch shouldn't be necessary: the doorbell is already set during queue
> allocation before requset_irq.
>
> The test doesn't seem like this patch would help either. It sounds
> more like you're hitting somethine else if you don't have this fix:
>
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/?h=for-linus&id=9bf2b972afeaffd173fe2ce211ebc555ea7e8a87
>
> If you do have that fix already, I'd like to see the panic stack trace
> (assuming that's what happened).
Yup, having that commit.
I'm going to reproduce (with current Linus' master) w/o the patch applied
later today.
--
Johannes Thumshirn Storage
jthumshirn@...e.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Powered by blists - more mailing lists