Re: [PATCH] scsi: ibmvfc: Stop using scsi_cmnd.tag

2021-08-17 Thread Bart Van Assche
On 8/17/21 6:43 AM, John Garry wrote: > Use scsi_cmd_to_rq(scsi_cmnd)->tag in preference to scsi_cmnd.tag. Reviewed-by: Bart Van Assche

Re: [powerpc][next-20210625] WARN block/mq-deadline-main.c:743 during boot

2021-06-27 Thread Bart Van Assche
On 6/27/21 6:30 AM, Sachin Sant wrote: > While booting 5.13.0-rc7-next-20210625 on POWER9 LPAR following warning > is seen [ ... ] Please help with testing of the patch that is available at https://lore.kernel.org/linux-block/2021062722.12720-1-bvanass...@acm.org/T/#u Thanks, Bart.

Re: [dm-devel] [PATCH 06/18] bvec: add a bvec_kmap_local helper

2021-06-16 Thread Bart Van Assche
On 6/15/21 6:24 AM, Christoph Hellwig wrote: > +/** > + * bvec_kmap_local - map a bvec into the kernel virtual address space > + * @bvec: bvec to map > + * > + * Must be called on single-page bvecs only. Call kunmap_local on the > returned > + * address to unmap. > + */ > +static inline void

Re: [PATCH 08/16] dm-writecache: use bvec_kmap_local instead of bvec_kmap_irq

2021-06-08 Thread Bart Van Assche
On 6/8/21 9:05 AM, Christoph Hellwig wrote: > diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c > index aecc246ade26..93ca454eaca9 100644 > --- a/drivers/md/dm-writecache.c > +++ b/drivers/md/dm-writecache.c > @@ -1205,14 +1205,13 @@ static void memcpy_flushcache_optimized(void

Re: [PATCH 03/16] bvec: fix the include guards for bvec.h

2021-06-08 Thread Bart Van Assche
On 6/8/21 9:05 AM, Christoph Hellwig wrote: > Fix the include guards to match the file naming. Reviewed-by: Bart Van Assche

Re: [PATCH 02/16] MIPS: don't include in

2021-06-08 Thread Bart Van Assche
-7,8 +7,6 @@ > #ifndef __ASM_RC32434_RB_H > #define __ASM_RC32434_RB_H > > -#include > - > #define REGBASE 0x1800 > #define IDT434_REG_BASE ((volatile void *) KSEG1ADDR(REGBASE)) > #define UART0BASE0x58000 Reviewed-by: Bart Van Assche

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2021-01-04 Thread Bart Van Assche
On 1/4/21 2:50 PM, Finn Thain wrote: > On Mon, 4 Jan 2021, Bart Van Assche wrote: >> Additionally, there is a good alternative available for the sbp driver. >> Every system I know of that is equipped with a Firewire port also has an >> Ethernet port. So users who want t

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2021-01-04 Thread Bart Van Assche
On 6/16/20 7:07 PM, Finn Thain wrote: > On Tue, 16 Jun 2020, Bart Van Assche wrote: >> As far as I know the sbp driver only has had one user ever and that user >> is no longer user the sbp driver. > > So, you estimate the userbase at zero. Can you give a confidence level?

Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver

2020-06-16 Thread Bart Van Assche
On 2020-06-16 02:42, Finn Thain wrote: > Martin said, "I'd appreciate a patch to remove it" > > And Bart said, "do you want to keep this driver in the kernel tree?" > > AFAICT both comments are quite ambiguous. I don't see an actionable > request, just an expression of interest from people

Re: lockdep warning while booting POWER9 PowerNV

2019-09-04 Thread Bart Van Assche
On 8/30/19 2:13 PM, Qian Cai wrote: https://raw.githubusercontent.com/cailca/linux-mm/master/powerpc.config Once in a while, booting an IBM POWER9 PowerNV system (8335-GTH) would generate a warning in lockdep_register_key() at, if (WARN_ON_ONCE(static_obj(key))) because key =

Re: [5.3.0-rc4-next][bisected 882632][qla2xxx] WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784 qla2x00_status_entry.isra

2019-08-14 Thread Bart Van Assche
On 8/14/19 10:18 AM, Abdul Haleem wrote: On Wed, 2019-08-14 at 10:05 -0700, Bart Van Assche wrote: On 8/14/19 9:52 AM, Abdul Haleem wrote: Greeting's Today's linux-next kernel (5.3.0-rc4-next-20190813) booted with warning on my powerpc power 8 lpar The WARN_ON_ONCE() was introduced

Re: [5.3.0-rc4-next][bisected 882632][qla2xxx] WARNING: CPU: 10 PID: 425 at drivers/scsi/qla2xxx/qla_isr.c:2784 qla2x00_status_entry.isra

2019-08-14 Thread Bart Van Assche
On 8/14/19 9:52 AM, Abdul Haleem wrote: > Greeting's > > Today's linux-next kernel (5.3.0-rc4-next-20190813) booted with warning on > my powerpc power 8 lpar > > The WARN_ON_ONCE() was introduced by commit 88263208 (scsi: qla2xxx: Complain > if sp->done() is not...) > > boot logs: > >

Re: [PATCH v3 03/24] drivers/block/z2ram: use ioremap_wt() instead of __ioremap(_PAGE_WRITETHRU)

2018-10-09 Thread Bart Van Assche
On Tue, 2018-10-09 at 13:51 +, Christophe Leroy wrote: > _PAGE_WRITETHRU is a target specific flag. Prefer generic functions. > > Acked-by: Geert Uytterhoeven > Signed-off-by: Christophe Leroy Hi Geert, All patches that have been applied to this driver since 2005 are API refactoring

Re: [4.18.0-rc4][bisected a063057d][mpt3sas] WARNING: CPU: 87 PID: 18868 at block/blk-core.c:781 blk_cleanup_queue+0x20c/0x220

2018-07-16 Thread Bart Van Assche
On Mon, 2018-07-16 at 14:23 +0530, Abdul Haleem wrote: > mpt3sas module unload triggered a warning at block/blk-core.c:781 on a > powerpc bare-metal running mainline kernel > > WARN_ON_ONCE() was introduced with commit a063057 : block: Fix a race > between request queue removal and the block

Re: Fwd: [powerpc/Baremetal]Kernel OOPS while executing memory hotplug on Power8 baremetal

2018-06-07 Thread Bart Van Assche
On Thu, 2018-06-07 at 12:56 +0530, Venkat Rao B wrote: > On Thursday 07 June 2018 12:46 PM, Bart Van Assche wrote: > > On Thu, 2018-06-07 at 12:38 +0530, vrbagal1 wrote: > > > Observing Kernel oops and machine reboots while executing memory hotplug > > > test case,

Re: Fwd: [powerpc/Baremetal]Kernel OOPS while executing memory hotplug on Power8 baremetal

2018-06-07 Thread Bart Van Assche
On Thu, 2018-06-07 at 12:38 +0530, vrbagal1 wrote: > Observing Kernel oops and machine reboots while executing memory hotplug > test case, on Power8 Baremetal machine. > > I see this is introduced some where between rc6 and 4.17. Please provide the exact versions (git commit IDs) of the kernel

Re: [linux-next][qla2xxx][85caa95]kernel BUG at lib/list_debug.c:31!

2018-01-09 Thread Bart Van Assche
On Tue, 2018-01-09 at 14:44 +0530, Abdul Haleem wrote: > Greeting's, > > Linux next kernel panics on powerpc when module qla2xxx is load/unload. > > Machine Type: Power 8 PowerVM LPAR > Kernel : 4.15.0-rc2-next-20171211 > gcc : version 4.8.5 > Test type: module load/unload few times > > Trace

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

2017-08-18 Thread Bart Van Assche
On Fri, 2017-08-18 at 16:57 -0500, Brian King wrote: > To add to my analysis above, #9 should not be there... It looks like > jiffies_at_alloc would also be getting reinitialized in this case, resulting > in > a perpetual retry, which is what I was seeing. Hello Brian, Some time ago I noticed

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

2017-08-18 Thread Bart Van Assche
On Fri, 2017-08-18 at 16:04 -0500, Brian King wrote: > I think I have an understanding what is going on and why Bart's patch is > causing problems for ipr. > I can work around the boot hang in ipr, but ultimately I think we need to > figure out a fix > in scsi / block. I added some tracing and

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

2017-08-17 Thread Bart Van Assche
On Wed, 2017-08-16 at 18:18 -0500, Brian King wrote: > On 08/16/2017 12:21 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: > > > As of next-20170809, linux-next on powerpc boot hung with below trace > > > message. > > > &g

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

2017-08-17 Thread Bart Van Assche
On Wed, 2017-08-16 at 15:10 -0500, Brian King wrote: > On 08/16/2017 01:15 PM, Bart Van Assche wrote: > > On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote: > > > Linux-next booted with the below warnings on powerpc > > > > > >

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

2017-08-16 Thread Bart Van Assche
On Wed, 2017-08-16 at 22:30 +0530, Abdul Haleem wrote: > As of next-20170809, linux-next on powerpc boot hung with below trace > message. > [ ... ] > System booted fine when the below commit is reverted: Hello Abdul, Can you check whether applying the following commit on top of next-20170809

Re: WARNING: CPU: 15 PID: 0 at block/blk-mq.c:1111 __blk_mq_run_hw_queue+0x1d8/0x1f0

2017-08-16 Thread Bart Van Assche
On Wed, 2017-08-16 at 23:37 +0530, Abdul Haleem wrote: > Linux-next booted with the below warnings on powerpc > > [ ... ] > > boot warnings: > -- > kvm: exiting hardware virtualization > [ cut here ] > WARNING: CPU: 15 PID: 0 at block/blk-mq.c:

Re: [BUG][bisected 270065e] linux-next fails to boot on powerpc

2017-08-16 Thread Bart Van Assche
for-next' > > System booted fine when the below commit is reverted: > > commit 270065e92c317845d69095ec8e3d18616b5b39d5 > Author: Bart Van Assche <bart.vanass...@wdc.com> > Date: Thu Aug 3 14:40:14 2017 -0700 > > scsi: scsi-mq: Always unprepare before requeuin

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

2017-07-28 Thread Bart Van Assche
On Fri, 2017-07-28 at 08:25 -0600, Jens Axboe wrote: > On 07/28/2017 12:19 AM, Michael Ellerman wrote: > > OK, so the resolution is "fix it in IPR" ? > > I'll leave that to the SCSI crew. But at least one bug is in IPR, if you > look at the call trace: > > - timer function triggers, runs

Re: blk_mq_sched_insert_request: inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage

2017-07-27 Thread Bart Van Assche
e following: Subject: [PATCH] blk-mq: Make it safe to call blk_mq_start_hw_queues() from interrupt context blk_mq_start_hw_queues() triggers a queue run. Some functions that get called to run a queue, e.g. dd_dispatch_request(), are not IRQ-safe. Hence run the queue asynchronously if blk_mq_start_hw_queues(

[PATCH v3 03/37] treewide: Consolidate set_dma_ops() implementations

2017-01-20 Thread Bart Van Assche
Now that all set_dma_ops() implementations are identical (ignoring BUG_ON() statements), remove the architecture specific definitions and add a definition in . Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: C

[PATCH v2 03/26] treewide: Consolidate set_dma_ops() implementations

2017-01-12 Thread Bart Van Assche
Now that all set_dma_ops() implementations are identical (ignoring BUG_ON() statements), remove the architecture specific definitions and add a definition in . Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: C

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread Bart Van Assche
attached patches? These three patches are a splitup of the single patch at the start of this e-mail thread. Thanks, Bart.From a6fe3a6db80f2bc359e049b72e13aa171fff6ffa Mon Sep 17 00:00:00 2001 From: Bart Van Assche <bart.vanass...@sandisk.com> Date: Wed, 11 Jan 2017 13:31:42 -0800 Subject: [PATC

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread Bart Van Assche
On Wed, 2017-01-11 at 07:48 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > > transfer data between memory and PCIe adapter. Because of performa

Re: [PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-11 Thread Bart Van Assche
On Wed, 2017-01-11 at 07:46 +0100, Greg Kroah-Hartman wrote: > On Tue, Jan 10, 2017 at 04:56:41PM -0800, Bart Van Assche wrote: > > Several RDMA drivers, e.g. drivers/infiniband/hw/qib, use the CPU to > > transfer data between memory and PCIe adapter. Because of performa

[PATCH 1/9] treewide: Constify most dma_map_ops structures

2017-01-10 Thread Bart Van Assche
ap_ops sn_dma_ops/' arch/ia64/sn/pci/pci_dma.c Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> Reviewed-by: Christoph Hellwig <h...@lst.de> Cc: Aurelien Jacquiot <a-jacqu...@ti.com> Cc: Catalin Marinas <catalin.mari...@arm.com> Cc: Chris Zankel <ch...@zan

[PATCH 2/9] Move dma_ops from archdata into struct device

2017-01-10 Thread Bart Van Assche
the dma_map_ops pointer. Additionally, introduce the function set_dma_ops() that will be used by a later patch in this series. Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Aurelien Jacquiot <a-jacqu...@ti.com> C

Re: Regression in 3.15 on POWER8 with multipath SCSI

2014-07-02 Thread Bart Van Assche
On 07/01/14 21:39, Mike Snitzer wrote: (btw, Bart Van Assche also has issues with commit e8099177 due to hangs during cable pull testing of mpath devices -- Bart: curious to know if your cable pull tests pass if you just revert bcccff93). Sorry but even with bcccff93 reverted after a few

Re: [PATCH 2/4] i2c/chips: Remove deprecated pcf8575-driver

2009-09-10 Thread Bart Van Assche
, finally remove it. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Bart Van Assche bart.vanass...@gmail.com Cc: Jean Delvare kh...@linux-fr.org ---  Documentation/i2c/chips/pcf8575 |   69 --  drivers/i2c/chips/Kconfig       |   18  drivers/i2c/chips/Makefile      |    1

[PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

2008-06-28 Thread Bart Van Assche
expects it. Additionally, the __inline__ keyword is replaced by inline, as checkpatch expects. Signed-off-by: Bart Van Assche [EMAIL PROTECTED] diff -uprN orig/linux-2.6.25.9/include/asm-powerpc/spinlock.h linux-2.6.25.9/include/asm-powerpc/spinlock.h --- orig/linux-2.6.25.9/include/asm-powerpc

Re: [PATCH 2.6.25.9] Make sure that include/asm-powerpc/spinlock.h does not trigger compilation warnings

2008-06-28 Thread Bart Van Assche
On Sat, Jun 28, 2008 at 5:07 PM, Kumar Gala [EMAIL PROTECTED] wrote: On Jun 28, 2008, at 1:51 AM, Bart Van Assche wrote: When compiling kernel modules for ppc that include linux/spinlock.h, gcc prints a warning message every time it encounters a function declaration where the inline keyword

Re: section mismatch warnings in current git head for powerpc

2008-05-22 Thread Bart Van Assche
On Thu, May 22, 2008 at 7:22 PM, Chris Friesen [EMAIL PROTECTED] wrote: I got the following warnings when building current git head for powerpc 64bit: Something that should be fixed, but not something to worry about. Similar warnings appear when building the kernel for x86_64. See also