Re: Oops when completing request on the wrong queue

Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> writes: > We, IBM, have been experiencing eventual Oops when stressing IO at the > same time we add/remove processors. The Oops happens in the IRQ path, > when we try to complete a request that was apparently meant for

Re: Oops when completing request on the wrong queue

59 STATE=1 while true; do for i in $(seq 1 ${MAXCPUS}); do if (($i%8)); then echo $STATE > /sys/devices/system/cpu/cpu$i/online fi done if [[ $STATE -eq 1 ]]; then STATE=0 else STATE=1 fi done -- Gabriel Krisman Bertazi -- To unsubscribe f

Re: Oops when completing request on the wrong queue

revent blk_mq_hctx_next_cpu from scheduling dead cpus in the first place, right.. How do you feel about the following RFC? I know it's not a complete fix, but it feels like a good improvement to me. http://www.spinics.net/lists/linux-scsi/msg98608.html -- Gabriel Krisman Bertazi -- To unsub

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig <h...@lst.de> writes: > On Thu, Sep 29, 2016 at 03:45:29PM -0300, Gabriel Krisman Bertazi wrote: >> I'm stepping up to assist with the genwqe_card driver just now, since we >> (ibm) missed some of the last patches that went in. I'll add myself to >>

Re: [PATCH 5/6] genwqe: use pci_irq_allocate_vectors

Christoph Hellwig <h...@lst.de> writes: > On Thu, Sep 29, 2016 at 03:28:02PM -0300, Gabriel Krisman Bertazi wrote: >> Christoph Hellwig <h...@lst.de> writes: >> >> > Simply the interrupt setup by using the new PCI layer helpers. >> >> Good clean u

[PATCH] blk-mq: Always schedule hctx->next_cpu

eally doesn't matter, since it still executes BLK_MQ_CPU_WORK_BATCH times in a row before switching to another CPU. Fixes: 0e87e58bf60e ("blk-mq: improve warning for running a queue on the wrong CPU") Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> --- block/blk-

[PATCH v2 1/2] blk-mq: Fix failed allocation path when mapping queues

9ebce0] c038dc28 do_io_submit+0x368/0x730 [c00fe99ebe30] c0009404 system_call+0x38/0xec Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc: Brian King <brk...@linux.vnet.ibm.com> Cc: Douglas Miller <dougm...@linux.vnet.ibm.com> Cc: linux-block@vge

[PATCH v2 2/2] blk-mq: Avoid memory reclaim when remapping queues

] [c030fe6c] __vfs_write+0x6c/0x1e0 [c00f0160bd90] [c0311490] vfs_write+0xd0/0x270 [c00f0160bde0] [c03131fc] SyS_write+0x6c/0x110 [c00f0160be30] [c0009204] system_call+0x38/0xec Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc:

[PATCH] blk-mq: Drop explicit timeout sync in hotplug

ter reference in blk_mq_timeout_work. Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc: Ming Lei <ming@canonical.com> --- block/blk-mq.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 9d4a1d63

[PATCH 2/2] blk-mq: Avoid memory reclaim when remapping queues

[c00f0160bd90] [c0311490] vfs_write+0xd0/0x270 [c00f0160bde0] [c03131fc] SyS_write+0x6c/0x110 [c00f0160be30] [c0009204] system_call+0x38/0xec Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc: Brian King <brk...@linux.vnet.ibm.com> Cc: Douglas M

[PATCH 1/2] blk-mq: Fix failed allocation path when mapping queues

9ebce0] c038dc28 do_io_submit+0x368/0x730 [c00fe99ebe30] c0009404 system_call+0x38/0xec Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc: Brian King <brk...@linux.vnet.ibm.com> Cc: Douglas Miller <dougm...@linux.vnet.ibm.com> Cc: linux-block@vge

[PATCH RFC 1/2] blk-mq: Fix failed allocation path when mapping queues

Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc: Brian King <brk...@linux.vnet.ibm.com> Cc: Jens Axboe <ax...@fb.com> --- block/blk-mq.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/block/blk-mq.c b/block/blk

[PATCH RESEND v2 2/2] blk-mq: Avoid memory reclaim when remapping queues

] [c030fe6c] __vfs_write+0x6c/0x1e0 [c00f0160bd90] [c0311490] vfs_write+0xd0/0x270 [c00f0160bde0] [c03131fc] SyS_write+0x6c/0x110 [c00f0160be30] [c0009204] system_call+0x38/0xec Signed-off-by: Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> Cc:

Re: [PATCH v2 1/2] blk-mq: Fix failed allocation path when mapping queues

Gabriel Krisman Bertazi <kris...@linux.vnet.ibm.com> writes: > My one concern about this patch is if remapping an arbitrary queue to > hctx_0 could result in outstanding requests getting submitted to the > wrong hctx. I couldn't observe this happening during tests, but I'm not

Re: [PATCH] blk-mq: Take tagset lock when updaing hw queues

ling the assertion. > > This patch takes the lock within the blk-mq function so the drivers do > not have to be modified in order to be safe. > > Fixes: 705cda97e ("blk-mq: Make it safe to use RCU to iterate over > blk_mq_tag_set.tag_list") > > Reported-by: Gabriel

Re: WARNING triggers at blk_mq_update_nr_hw_queues during nvme_reset_work

Keith Busch <keith.bu...@intel.com> writes: > On Tue, May 30, 2017 at 02:00:44PM -0300, Gabriel Krisman Bertazi wrote: >> Since the merge window for 4.12, one of the machines in Intel's CI >> started to hit the WARN_ON below at blk_mq_update_nr_hw_queues during an >>