Re: General protection fault with use_blk_mq=1.

> Il giorno 29 mar 2018, alle ore 05:22, Jens Axboe ha > scritto: > > On 3/28/18 9:13 PM, Zephaniah E. Loss-Cutler-Hull wrote: >> On 03/28/2018 06:02 PM, Jens Axboe wrote: >>> On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote: I am not subscribed to any of the

Re: General protection fault with use_blk_mq=1.

> Il giorno 29 mar 2018, alle ore 03:02, Jens Axboe ha > scritto: > > On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote: >> I am not subscribed to any of the lists on the To list here, please CC >> me on any replies. >> >> I am encountering a fairly consistent crash

Re: General protection fault with use_blk_mq=1.

On 3/28/18 9:13 PM, Zephaniah E. Loss-Cutler-Hull wrote: > On 03/28/2018 06:02 PM, Jens Axboe wrote: >> On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote: >>> I am not subscribed to any of the lists on the To list here, please CC >>> me on any replies. >>> >>> I am encountering a fairly

Re: General protection fault with use_blk_mq=1.

On 03/28/2018 06:02 PM, Jens Axboe wrote: > On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote: >> I am not subscribed to any of the lists on the To list here, please CC >> me on any replies. >> >> I am encountering a fairly consistent crash anywhere from 15 minutes to >> 12 hours after boot

Re: General protection fault with use_blk_mq=1.

On 3/28/18 5:03 PM, Zephaniah E. Loss-Cutler-Hull wrote: > I am not subscribed to any of the lists on the To list here, please CC > me on any replies. > > I am encountering a fairly consistent crash anywhere from 15 minutes to > 12 hours after boot with scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1>

General protection fault with use_blk_mq=1.

I am not subscribed to any of the lists on the To list here, please CC me on any replies. I am encountering a fairly consistent crash anywhere from 15 minutes to 12 hours after boot with scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 The crash looks like: [ 5466.075993] general protection fault:

Re: [PATCH 3/3] nvme-pci: Separate IO and admin queue IRQ vectors

On Wed, Mar 28, 2018 at 09:32:14AM +0200, Christoph Hellwig wrote: > On Tue, Mar 27, 2018 at 09:39:08AM -0600, Keith Busch wrote: > > - return blk_mq_pci_map_queues(set, to_pci_dev(dev->dev), 0); > > + return blk_mq_pci_map_queues(set, to_pci_dev(dev->dev), > > +

Re: [PATCH 2/2] loop: use interruptible lock in ioctls

On Wed, Mar 28, 2018 at 03:18:52PM +0200, David Sterba wrote: > On Mon, Mar 26, 2018 at 05:04:21PM -0700, Matthew Wilcox wrote: > > On Mon, Mar 26, 2018 at 04:16:26PM -0700, Omar Sandoval wrote: > > > Even after the previous patch to drop lo_ctl_mutex while calling > > > vfs_getattr(), there are

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

FWIW, these logs were from a different system (with less disks and cpus). the related log is [4.114191] dasd-eckd.2aa01a: 0.0.3f77: New DASD 3390/0C (CU 3990/01) with 30051 cylinders, 15 heads, 224 sectors [4.114852] dasd-eckd.2aa01a: 0.0.3f74: New DASD 3390/0C (CU 3990/01) with 30051

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

With that patch I now get: [ 40.620619] virbr0: port 1(virbr0-nic) entered disabled state [ 47.418592] run queue from wrong CPU 3, hctx inactive [ 47.418602] CPU: 3 PID: 2153 Comm: kworker/3:1H Tainted: GW 4.16.0-rc7+ #27 [ 47.418604] Hardware name: IBM 2964 NC9 704 (LPAR)

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

On 03/28/2018 05:26 PM, Ming Lei wrote: > Hi Christian, > > On Wed, Mar 28, 2018 at 09:45:10AM +0200, Christian Borntraeger wrote: >> FWIW, this patch does not fix the issue for me: >> >> ostname=? addr=? terminal=? res=success' >> [ 21.454961] WARNING: CPU: 3 PID: 1882 at block/blk-mq.c:1410

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

Hi Christian, On Wed, Mar 28, 2018 at 09:45:10AM +0200, Christian Borntraeger wrote: > FWIW, this patch does not fix the issue for me: > > ostname=? addr=? terminal=? res=success' > [ 21.454961] WARNING: CPU: 3 PID: 1882 at block/blk-mq.c:1410 > __blk_mq_delay_run_hw_queue+0xbe/0xd8 > [

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

On 3/28/18 8:38 AM, Jens Axboe wrote: > On 3/28/18 1:45 AM, Christian Borntraeger wrote: >> FWIW, this patch does not fix the issue for me: > > Looks like I didn't do the delayed path. How about the below? OK, final version... This is more in line with what I originally suggested. diff --git

RE: [PATCH 1/3] blk-mq: Allow PCI vector offset for mapping queues

> -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of Keith Busch > Sent: Tuesday, March 27, 2018 10:39 AM > To: Linux NVMe ; Linux Block bl...@vger.kernel.org> > Cc: Christoph Hellwig

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

On 3/28/18 1:45 AM, Christian Borntraeger wrote: > FWIW, this patch does not fix the issue for me: Looks like I didn't do the delayed path. How about the below? diff --git a/block/blk-mq.c b/block/blk-mq.c index 16e83e6df404..fd663ae1094c 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@

Re: [PATCH 2/2] loop: use interruptible lock in ioctls

On Mon, Mar 26, 2018 at 05:04:21PM -0700, Matthew Wilcox wrote: > On Mon, Mar 26, 2018 at 04:16:26PM -0700, Omar Sandoval wrote: > > Even after the previous patch to drop lo_ctl_mutex while calling > > vfs_getattr(), there are other cases where we can end up sleeping for a > > long time while

Re: [PATCH 4/4] nvme: lightnvm: add late setup of block size and metadata

On 28/03/2018 10.28, Christoph Hellwig wrote: I really don't want more lightnvm cruft in the core. We'll need a proper abstraction.c I agree, we should get that moving, and make a proper abstraction for it. Also with respect to how an SMR interface in general is integrated into NVMe. The

Re: [PATCH] blk-mq: only run mapped hw queues in blk_mq_run_hw_queues()

FWIW, this patch does not fix the issue for me: ostname=? addr=? terminal=? res=success' [ 21.454961] WARNING: CPU: 3 PID: 1882 at block/blk-mq.c:1410 __blk_mq_delay_run_hw_queue+0xbe/0xd8 [ 21.454968] Modules linked in: scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_mirror dm_region_hash dm_log

Re: [PATCH 4/4] nvme: lightnvm: add late setup of block size and metadata

I really don't want more lightnvm cruft in the core. We'll need a proper abstraction.c On Fri, Mar 23, 2018 at 12:00:08PM +0100, Matias Bjørling wrote: > On 02/05/2018 01:15 PM, Matias Bjørling wrote: > > The nvme driver sets up the size of the nvme namespace in two steps. > > First it

Re: [PATCH 3/3] iomap: Use FUA for pure data O_DSYNC DIO writes

> if (iomap->flags & IOMAP_F_NEW) > need_zeroout = true; > + else { Curly braces on both sides of the else, please. > if (dio->flags & IOMAP_DIO_WRITE) { > - bio_set_op_attrs(bio, REQ_OP_WRITE, REQ_SYNC | >

Re: [PATCH 2/3] iomap: iomap_dio_rw() handles all sync writes

> +#define IOMAP_DIO_WRITE_SYNC (1 << 29) Actually based on the next patch can we rename this to something like: IOMAP_DIO_NEED_SYNC? That makes the usage a little more clear.

Re: [PATCH 2/3] iomap: iomap_dio_rw() handles all sync writes

> @@ -769,12 +777,9 @@ static void iomap_dio_complete_work(struct work_struct > *work) > { > struct iomap_dio *dio = container_of(work, struct iomap_dio, aio.work); > struct kiocb *iocb = dio->iocb; > - bool is_write = (dio->flags & IOMAP_DIO_WRITE); > ssize_t ret; > >

Re: [PATCH 1/3] xfs: move generic_write_sync calls inwards

> + /* > + * capture amount written on completion as we can't reliably account > + * for it on submission Captialize the first c, and a . at the end of the sentence please. Otherwise looks good: Reviewed-by: Christoph Hellwig

Re: [PATCH 3/3] nvme-pci: Separate IO and admin queue IRQ vectors

On Tue, Mar 27, 2018 at 09:39:08AM -0600, Keith Busch wrote: > - return blk_mq_pci_map_queues(set, to_pci_dev(dev->dev), 0); > + return blk_mq_pci_map_queues(set, to_pci_dev(dev->dev), > + dev->num_vecs > 1); Can you turn this into: - return

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Mon, 2018-03-26 at 10:39 +0200, Thorsten Leemhuis wrote: > Lo! Your friendly Linux regression tracker here ;-) > > On 08.03.2018 14:18, Artem Bityutskiy wrote: > > On Thu, 2018-03-08 at 18:53 +0800, Ming Lei wrote: > > > This patchset tries to spread among online CPUs as far as possible, so >