Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Fri, Jan 10, 2020 at 08:10:28AM +0100, Christian Zigotzky wrote: > Hi All, > > The SCSI cards work again. [1, 2] > > Sorry for bothering you. No problem, and sorry for not following up earlier. The Christmas holiday and catch up phase led to a lot of delay. Thanks a lot for taking care of these ppc platforms!
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
Hi All, The SCSI cards work again. [1, 2] Sorry for bothering you. Thanks, Christian [1] http://forum.hyperion-entertainment.com/viewtopic.php?f=58=49603=1adf9e6d558c136c1ad4ff15c44212ba#p49599 [2] https://bugzilla.kernel.org/show_bug.cgi?id=205201
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
I think we have to wait to Roland’s test results with his SCSI PCI card. Christian Sent from my iPhone > On 4. Dec 2019, at 09:56, Christoph Hellwig wrote: > >> On Wed, Nov 27, 2019 at 08:56:25AM +0200, Mike Rapoport wrote: >>> On Tue, Nov 26, 2019 at 05:40:26PM +0100, Christoph Hellwig wrote: On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote: Hello Christoph, The PCI TV card works with your patch! I was able to patch your Git kernel with the patch above. I haven't found any error messages in the dmesg yet. >>> >>> Thanks. Unfortunately this is a bit of a hack as we need to set >>> the mask based on runtime information like the magic FSL PCIe window. >>> Let me try to draft something better up, and thanks already for testing >>> this one! >> >> Maybe we'll simply force bottom up allocation before calling >> swiotlb_init()? Anyway, it's the last memblock allocation. > > So I think we should go with this fix (plus a source code comment) for > now. Revamping the whole memory initialization is going to take a > while, and this fix also is easily backportable.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Wed, Nov 27, 2019 at 08:56:25AM +0200, Mike Rapoport wrote: > On Tue, Nov 26, 2019 at 05:40:26PM +0100, Christoph Hellwig wrote: > > On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote: > > > Hello Christoph, > > > > > > The PCI TV card works with your patch! I was able to patch your Git > > > kernel > > > with the patch above. > > > > > > I haven't found any error messages in the dmesg yet. > > > > Thanks. Unfortunately this is a bit of a hack as we need to set > > the mask based on runtime information like the magic FSL PCIe window. > > Let me try to draft something better up, and thanks already for testing > > this one! > > Maybe we'll simply force bottom up allocation before calling > swiotlb_init()? Anyway, it's the last memblock allocation. So I think we should go with this fix (plus a source code comment) for now. Revamping the whole memory initialization is going to take a while, and this fix also is easily backportable.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 27 November 2019 at 07:56 am, Mike Rapoport wrote: Maybe we'll simply force bottom up allocation before calling swiotlb_init()? Anyway, it's the last memblock allocation. diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 62f74b1b33bd..771e6cf7e2b9 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -286,14 +286,15 @@ void __init mem_init(void) /* * book3s is limited to 16 page sizes due to encoding this in * a 4-bit field for slices. */ BUILD_BUG_ON(MMU_PAGE_COUNT > 16); #ifdef CONFIG_SWIOTLB + memblock_set_bottom_up(true); swiotlb_init(0); #endif high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); set_max_mapnr(max_pfn); memblock_free_all(); Hello Mike, I tested the latest Git kernel with your new patch today. My PCI TV card works without any problems. Thanks, Christian
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Wed, Nov 27, 2019 at 08:56:25AM +0200, Mike Rapoport wrote: > Maybe we'll simply force bottom up allocation before calling > swiotlb_init()? Anyway, it's the last memblock allocation. That should work, but I don't think it is the proper fix. The underlying issue here is that ZONE_DMA/DMA32 sizing is something that needs to be propagated to memblock and dma-direct as is based around addressing limitations. But our zone initialization is such a mess that we can't just reuse a variable. Nicolas has started to clean some of this up, but we need to clean that whole zone initialization mess up a lot more.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Tue, Nov 26, 2019 at 05:40:26PM +0100, Christoph Hellwig wrote: > On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote: > > Hello Christoph, > > > > The PCI TV card works with your patch! I was able to patch your Git kernel > > with the patch above. > > > > I haven't found any error messages in the dmesg yet. > > Thanks. Unfortunately this is a bit of a hack as we need to set > the mask based on runtime information like the magic FSL PCIe window. > Let me try to draft something better up, and thanks already for testing > this one! Maybe we'll simply force bottom up allocation before calling swiotlb_init()? Anyway, it's the last memblock allocation. diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index 62f74b1b33bd..771e6cf7e2b9 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -286,14 +286,15 @@ void __init mem_init(void) /* * book3s is limited to 16 page sizes due to encoding this in * a 4-bit field for slices. */ BUILD_BUG_ON(MMU_PAGE_COUNT > 16); #ifdef CONFIG_SWIOTLB + memblock_set_bottom_up(true); swiotlb_init(0); #endif high_memory = (void *) __va(max_low_pfn * PAGE_SIZE); set_max_mapnr(max_pfn); memblock_free_all(); -- Sincerely yours, Mike.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Tue, Nov 26, 2019 at 12:26:38PM +0100, Christian Zigotzky wrote: > Hello Christoph, > > The PCI TV card works with your patch! I was able to patch your Git kernel > with the patch above. > > I haven't found any error messages in the dmesg yet. Thanks. Unfortunately this is a bit of a hack as we need to set the mask based on runtime information like the magic FSL PCIe window. Let me try to draft something better up, and thanks already for testing this one!
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 25 November 2019 at 10:32 am, Mike Rapoport wrote:
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based on the bus dma mask limit, which is rather
interesting. swiotlb_init uses memblock_alloc_low to allocate the
buffer, and I'll need some help from Mike and the powerpc maintainers
to figure out how that select where to allocate the buffer from, and
how we can move it to a lower address. My gut feeling would be to try
to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably
without needing too much arch specific magic.
Presuming the problem is relevant for all CoreNet boards something like
this could work:
diff --git a/arch/powerpc/include/asm/dma.h b/arch/powerpc/include/asm/dma.h
index 1b4f0254868f..7c6cfeeaff52 100644
--- a/arch/powerpc/include/asm/dma.h
+++ b/arch/powerpc/include/asm/dma.h
@@ -347,5 +347,11 @@ extern int isa_dma_bridge_buggy;
#define isa_dma_bridge_buggy (0)
#endif
+#ifdef CONFIG_CORENET_GENERIC
+extern phys_addr_t ppc_dma_phys_limit;
+#define ARCH_LOW_ADDRESS_LIMIT (ppc_dma_phys_limit - 1)
+#endif
+
+
#endif /* __KERNEL__ */
#endif/* _ASM_POWERPC_DMA_H */
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index fe0606439b5a..346b436b6d3f 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -126,3 +126,7 @@ void __init mpc85xx_qe_par_io_init(void)
}
}
#endif
+
+#ifdef CONFIG_CORENET_GENERIC
+phys_addr_t ppc_dma_phys_limit = 0xUL;
+#endif
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 7ee2c6628f64..673bcbdc7c75 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -64,7 +64,7 @@ void __init corenet_gen_setup_arch(void)
mpc85xx_smp_init();
swiotlb_detect_4g();
-
+ ppc_dma_phys_limit = 0x0fffUL;
pr_info("%s board\n", ppc_md.name);
mpc85xx_qe_init();
Hello Mike,
My PCI TV card works also with your patch! Before I had to add "#include
" to the file "arch/powerpc/platforms/85xx/corenet_generic.c"
because of the following error:
--
CC arch/powerpc/platforms/85xx/corenet_generic.o
CC ipc/util.o
CC ipc/msgutil.o
arch/powerpc/platforms/85xx/corenet_generic.c: In function
‘corenet_gen_setup_arch’:
arch/powerpc/platforms/85xx/corenet_generic.c:77:2: error:
‘ppc_dma_phys_limit’ undeclared (first use in this function); did you
mean ‘cpu_to_phys_id’?
ppc_dma_phys_limit = 0x0fffUL;
^~
cpu_to_phys_id
arch/powerpc/platforms/85xx/corenet_generic.c:77:2: note: each
undeclared identifier is reported only once for each function it appears in
scripts/Makefile.build:265: recipe for target
'arch/powerpc/platforms/85xx/corenet_generic.o' failed
make[3]: *** [arch/powerpc/platforms/85xx/corenet_generic.o] Error 1
scripts/Makefile.build:509: recipe for target
'arch/powerpc/platforms/85xx' failed
make[2]: *** [arch/powerpc/platforms/85xx] Error 2
scripts/Makefile.build:509: recipe for target 'arch/powerpc/platforms'
failed
make[1]: *** [arch/powerpc/platforms] Error 2
Makefile:1652: recipe for target 'arch/powerpc' failed
make: *** [arch/powerpc] Error 2
--
After that I was able to compile the latest Git kernel with your patch.
Thanks,
Christian
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote: On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote: Hello Christoph, Please find attached the dmesg of your Git kernel. Thanks. It looks like on your platform the swiotlb buffer isn't actually addressable based on the bus dma mask limit, which is rather interesting. swiotlb_init uses memblock_alloc_low to allocate the buffer, and I'll need some help from Mike and the powerpc maintainers to figure out how that select where to allocate the buffer from, and how we can move it to a lower address. My gut feeling would be to try to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably without needing too much arch specific magic. As a quick hack can you try this patch on top of the tree from Friday? diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f491690d54c6..e3f95c362922 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r) #define MEMBLOCK_LOW_LIMIT 0 #ifndef ARCH_LOW_ADDRESS_LIMIT -#define ARCH_LOW_ADDRESS_LIMIT 0xUL +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffUL #endif phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, Hello Christoph, The PCI TV card works with your patch! I was able to patch your Git kernel with the patch above. I haven't found any error messages in the dmesg yet. Thank you! Cheers, Christian
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 25 November 2019 at 10:32 am, Mike Rapoport wrote:
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
Hello Christoph,
Please find attached the dmesg of your Git kernel.
Thanks. It looks like on your platform the swiotlb buffer isn't
actually addressable based on the bus dma mask limit, which is rather
interesting. swiotlb_init uses memblock_alloc_low to allocate the
buffer, and I'll need some help from Mike and the powerpc maintainers
to figure out how that select where to allocate the buffer from, and
how we can move it to a lower address. My gut feeling would be to try
to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably
without needing too much arch specific magic.
Presuming the problem is relevant for all CoreNet boards something like
this could work:
diff --git a/arch/powerpc/include/asm/dma.h b/arch/powerpc/include/asm/dma.h
index 1b4f0254868f..7c6cfeeaff52 100644
--- a/arch/powerpc/include/asm/dma.h
+++ b/arch/powerpc/include/asm/dma.h
@@ -347,5 +347,11 @@ extern int isa_dma_bridge_buggy;
#define isa_dma_bridge_buggy (0)
#endif
+#ifdef CONFIG_CORENET_GENERIC
+extern phys_addr_t ppc_dma_phys_limit;
+#define ARCH_LOW_ADDRESS_LIMIT (ppc_dma_phys_limit - 1)
+#endif
+
+
#endif /* __KERNEL__ */
#endif/* _ASM_POWERPC_DMA_H */
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index fe0606439b5a..346b436b6d3f 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -126,3 +126,7 @@ void __init mpc85xx_qe_par_io_init(void)
}
}
#endif
+
+#ifdef CONFIG_CORENET_GENERIC
+phys_addr_t ppc_dma_phys_limit = 0xUL;
+#endif
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 7ee2c6628f64..673bcbdc7c75 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -64,7 +64,7 @@ void __init corenet_gen_setup_arch(void)
mpc85xx_smp_init();
swiotlb_detect_4g();
-
+ ppc_dma_phys_limit = 0x0fffUL;
pr_info("%s board\n", ppc_md.name);
mpc85xx_qe_init();
As a quick hack can you try this patch on top of the tree from Friday?
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index f491690d54c6..e3f95c362922 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct
memblock_region *r)
#define MEMBLOCK_LOW_LIMIT 0
#ifndef ARCH_LOW_ADDRESS_LIMIT
-#define ARCH_LOW_ADDRESS_LIMIT 0xUL
+#define ARCH_LOW_ADDRESS_LIMIT 0x0fffUL
#endif
phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
Hello Mike,
Many thanks for your patch! I will test it tomorrow.
Cheers,
Christian
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 25 November 2019 at 08:39 am, Christoph Hellwig wrote: On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote: Hello Christoph, Please find attached the dmesg of your Git kernel. Thanks. It looks like on your platform the swiotlb buffer isn't actually addressable based on the bus dma mask limit, which is rather interesting. swiotlb_init uses memblock_alloc_low to allocate the buffer, and I'll need some help from Mike and the powerpc maintainers to figure out how that select where to allocate the buffer from, and how we can move it to a lower address. My gut feeling would be to try to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably without needing too much arch specific magic. As a quick hack can you try this patch on top of the tree from Friday? diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f491690d54c6..e3f95c362922 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r) #define MEMBLOCK_LOW_LIMIT 0 #ifndef ARCH_LOW_ADDRESS_LIMIT -#define ARCH_LOW_ADDRESS_LIMIT 0xUL +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffUL #endif phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align, Hello Christoph, Thanks a lot for your help! I will test your patch tomorrow. Cheers, Christian
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Mon, Nov 25, 2019 at 08:39:23AM +0100, Christoph Hellwig wrote:
> On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote:
> > Hello Christoph,
> >
> > Please find attached the dmesg of your Git kernel.
>
> Thanks. It looks like on your platform the swiotlb buffer isn't
> actually addressable based on the bus dma mask limit, which is rather
> interesting. swiotlb_init uses memblock_alloc_low to allocate the
> buffer, and I'll need some help from Mike and the powerpc maintainers
> to figure out how that select where to allocate the buffer from, and
> how we can move it to a lower address. My gut feeling would be to try
> to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably
> without needing too much arch specific magic.
Presuming the problem is relevant for all CoreNet boards something like
this could work:
diff --git a/arch/powerpc/include/asm/dma.h b/arch/powerpc/include/asm/dma.h
index 1b4f0254868f..7c6cfeeaff52 100644
--- a/arch/powerpc/include/asm/dma.h
+++ b/arch/powerpc/include/asm/dma.h
@@ -347,5 +347,11 @@ extern int isa_dma_bridge_buggy;
#define isa_dma_bridge_buggy (0)
#endif
+#ifdef CONFIG_CORENET_GENERIC
+extern phys_addr_t ppc_dma_phys_limit;
+#define ARCH_LOW_ADDRESS_LIMIT (ppc_dma_phys_limit - 1)
+#endif
+
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DMA_H */
diff --git a/arch/powerpc/platforms/85xx/common.c
b/arch/powerpc/platforms/85xx/common.c
index fe0606439b5a..346b436b6d3f 100644
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -126,3 +126,7 @@ void __init mpc85xx_qe_par_io_init(void)
}
}
#endif
+
+#ifdef CONFIG_CORENET_GENERIC
+phys_addr_t ppc_dma_phys_limit = 0xUL;
+#endif
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index 7ee2c6628f64..673bcbdc7c75 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -64,7 +64,7 @@ void __init corenet_gen_setup_arch(void)
mpc85xx_smp_init();
swiotlb_detect_4g();
-
+ ppc_dma_phys_limit = 0x0fffUL;
pr_info("%s board\n", ppc_md.name);
mpc85xx_qe_init();
> As a quick hack can you try this patch on top of the tree from Friday?
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index f491690d54c6..e3f95c362922 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct
> memblock_region *r)
> #define MEMBLOCK_LOW_LIMIT 0
>
> #ifndef ARCH_LOW_ADDRESS_LIMIT
> -#define ARCH_LOW_ADDRESS_LIMIT 0xUL
> +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffUL
> #endif
>
> phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
--
Sincerely yours,
Mike.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Sat, Nov 23, 2019 at 12:42:27PM +0100, Christian Zigotzky wrote: > Hello Christoph, > > Please find attached the dmesg of your Git kernel. Thanks. It looks like on your platform the swiotlb buffer isn't actually addressable based on the bus dma mask limit, which is rather interesting. swiotlb_init uses memblock_alloc_low to allocate the buffer, and I'll need some help from Mike and the powerpc maintainers to figure out how that select where to allocate the buffer from, and how we can move it to a lower address. My gut feeling would be to try to do what arm64 does and define a new ARCH_LOW_ADDRESS_LIMIT, preferably without needing too much arch specific magic. As a quick hack can you try this patch on top of the tree from Friday? diff --git a/include/linux/memblock.h b/include/linux/memblock.h index f491690d54c6..e3f95c362922 100644 --- a/include/linux/memblock.h +++ b/include/linux/memblock.h @@ -344,7 +344,7 @@ static inline int memblock_get_region_node(const struct memblock_region *r) #define MEMBLOCK_LOW_LIMIT 0 #ifndef ARCH_LOW_ADDRESS_LIMIT -#define ARCH_LOW_ADDRESS_LIMIT 0xUL +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffUL #endif phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 21 November 2019 at 07:02 pm, Christoph Hellwig wrote: On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote: I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch attached) We have to wait to Rolands test results with his SCSI PCI card. I tested it today but my TV card doesn't work with this patch. I think we have two sorta overlapping issues here. One is that I think we need the bus_dma_limit, which should mostly help for something like a SCSI controller that doesn't need streaming mappings (btw, do we have more details on that somewhere?). And something weird with the videobuf things. Your change of the dma masks suggests that the driver doesn't do the right allocations and thus hits bounce buffering (swiotlb). We should fix that for real, but the fact that the bounce buffering itself also fails is even more interesting. Can you try this git branch: git://git.infradead.org/users/hch/misc.git fsl-dma-debugging Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/fsl-dma-debugging and send me the dmesg with that with your TV adapter? Hello Christoph, Please find attached the dmesg of your Git kernel. Thanks, Christian [0.00] OF: reserved mem: initialized node qman-fqd, compatible id fsl,qman-fqd [0.00] OF: reserved mem: initialized node qman-pfdr, compatible id fsl,qman-pfdr [0.00] OF: reserved mem: initialized node bman-fbpr, compatible id fsl,bman-fbpr [0.00] MMU: Supported page sizes [0.00] 4 KB as direct [0.00] 4096 KB as direct [0.00] 16384 KB as direct [0.00] 65536 KB as direct [0.00] 262144 KB as direct [0.00]1048576 KB as direct [0.00] MMU: Book3E HW tablewalk not supported [0.00] Linux version 5.4.0-rc9_A-EON_X5000-119069-gc70373c2f0af-dirty (christian@christian-TUXEDO-InfinityBook-14-v2) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #1 SMP PREEMPT Fri Nov 22 03:51:42 CET 2019 [0.00] Using CoreNet Generic machine description [0.00] Found legacy serial port 0 for /soc@ffe00/serial@11c500 [0.00] mem=ffe11c500, taddr=ffe11c500, irq=0, clk=4, speed=0 [0.00] Found legacy serial port 1 for /soc@ffe00/serial@11c600 [0.00] mem=ffe11c600, taddr=ffe11c600, irq=0, clk=4, speed=0 [0.00] Found legacy serial port 2 for /soc@ffe00/serial@11d500 [0.00] mem=ffe11d500, taddr=ffe11d500, irq=0, clk=4, speed=0 [0.00] Found legacy serial port 3 for /soc@ffe00/serial@11d600 [0.00] mem=ffe11d600, taddr=ffe11d600, irq=0, clk=4, speed=0 [0.00] CPU maps initialized for 1 thread per core [0.00] (thread shift is 0) [0.00] Allocated 1824 bytes for 4 pacas [0.00] - [0.00] phys_mem_size = 0x2 [0.00] dcache_bsize = 0x40 [0.00] icache_bsize = 0x40 [0.00] cpu_features = 0x0003008003b4 [0.00] possible= 0x0003009003b4 [0.00] always = 0x0003008003b4 [0.00] cpu_user_features = 0xcc008000 0x0800 [0.00] mmu_features = 0x000a0010 [0.00] firmware_features = 0x [0.00] - [0.00] CoreNet Generic board [0.00] barrier-nospec: using isync; sync as speculation barrier [0.00] barrier-nospec: patched 572 locations [0.00] Top of RAM: 0x2, Total RAM: 0x2 [0.00] Memory hole size: 0MB [0.00] Zone ranges: [0.00] DMA [mem 0x-0x7fff] [0.00] Normal [mem 0x8000-0x0001] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x0001] [0.00] Initmem setup node 0 [mem 0x-0x0001] [0.00] On node 0 totalpages: 2097152 [0.00] DMA zone: 7168 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 524288 pages, LIFO batch:63 [0.00] Normal zone: 21504 pages used for memmap [0.00] Normal zone: 1572864 pages, LIFO batch:63 [0.00] MMU: Allocated 2112 bytes of context maps for 255 contexts [0.00] percpu: Embedded 20 pages/cpu s45008 r0 d36912 u262144 [0.00] pcpu-alloc: s45008 r0 d36912 u262144 alloc=1*1048576 [0.00] pcpu-alloc: [0] 0 1 2 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 2068480 [0.00] Kernel command line: root=/dev/sda2 [0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) [0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) [
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 21. Nov 2019, at 19:02, Christoph Hellwig wrote: On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote: I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch attached) We have to wait to Rolands test results with his SCSI PCI card. I tested it today but my TV card doesn't work with this patch. I think we have two sorta overlapping issues here. One is that I think we need the bus_dma_limit, which should mostly help for something like a SCSI controller that doesn't need streaming mappings (btw, do we have more details on that somewhere?). And something weird with the videobuf things. Your change of the dma masks suggests that the driver doesn't do the right allocations and thus hits bounce buffering (swiotlb). We should fix that for real, but the fact that the bounce buffering itself also fails is even more interesting. Can you try this git branch: git://git.infradead.org/users/hch/misc.git fsl-dma-debugging Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/fsl-dma-debugging and send me the dmesg with that with your TV adapter? - - - Yes, I will test it at the weekend. Thanks for your help. Christian
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Thu, Nov 21, 2019 at 05:34:48PM +0100, Christian Zigotzky wrote: > I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch > attached) > > We have to wait to Rolands test results with his SCSI PCI card. I tested it > today but my TV card doesn't work with this patch. I think we have two sorta overlapping issues here. One is that I think we need the bus_dma_limit, which should mostly help for something like a SCSI controller that doesn't need streaming mappings (btw, do we have more details on that somewhere?). And something weird with the videobuf things. Your change of the dma masks suggests that the driver doesn't do the right allocations and thus hits bounce buffering (swiotlb). We should fix that for real, but the fact that the bounce buffering itself also fails is even more interesting. Can you try this git branch: git://git.infradead.org/users/hch/misc.git fsl-dma-debugging Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/fsl-dma-debugging and send me the dmesg with that with your TV adapter?
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
Am 21.11.19 um 14:33 schrieb Robin Murphy:
On 21/11/2019 12:21 pm, Christian Zigotzky wrote:
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote:
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote:
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote:
/*
* DMA addressing mode.
*
* 0 : 32 bit addressing for all chips.
* 1 : 40 bit addressing when supported by chip.
* 2 : 64 bit addressing when supported by chip,
* limited to 16 segments of 4 GB -> 64 GB max.
*/
#define SYM_CONF_DMA_ADDRESSING_MODE
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE
Cyrus config:
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
I will configure “0 : 32 bit addressing for all chips” for the
RC8. Maybe this is the solution.
0 means you are going to do bounce buffering a lot, which seems
generally like a bad idea.
But why are we talking about the sym53c8xx driver now? The last issue
you reported was about video4linux allocations.
Both drivers have the same problem. They don't work if we have more
than 3.5GB RAM. I try to find a solution until you have a good
solution. I have already a solution for V4L but I still need one for
the sym53c8xx driver.
OK, you mean that "0" is a bad idea but maybe it works until you have
a solution. ;-)
Is this on the same machine with the funny non-power-of-two
bus_dma_mask as your other report? If so, does Nicolas' latest
patch[1] help at all?
Robin.
[1]
https://lore.kernel.org/linux-iommu/20191121092646.8449-1-nsaenzjulie...@suse.de/T/#u
Robin,
I modified the patch and compiled a new RC8 of kernel 5.4 today. (patch
attached)
We have to wait to Rolands test results with his SCSI PCI card. I tested
it today but my TV card doesn't work with this patch.
Thanks
diff -rupN a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
--- a/arch/powerpc/sysdev/fsl_pci.c 2019-11-17 23:47:30.0 +0100
+++ b/arch/powerpc/sysdev/fsl_pci.c 2019-11-21 15:32:50.216488955 +0100
@@ -115,8 +115,8 @@ static void pci_dma_dev_setup_swiotlb(st
{
struct pci_controller *hose = pci_bus_to_host(pdev->bus);
- pdev->dev.bus_dma_mask =
- hose->dma_window_base_cur + hose->dma_window_size;
+ pdev->dev.bus_dma_limit =
+ hose->dma_window_base_cur + hose->dma_window_size - 1;
}
static void setup_swiotlb_ops(struct pci_controller *hose)
@@ -135,7 +135,7 @@ static void fsl_pci_dma_set_mask(struct
* mapping that allows addressing any RAM address from across PCI.
*/
if (dev_is_pci(dev) && dma_mask >= pci64_dma_offset * 2 - 1) {
- dev->bus_dma_mask = 0;
+ dev->bus_dma_limit = 0;
dev->archdata.dma_offset = pci64_dma_offset;
}
}
diff -rupN a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
--- a/drivers/iommu/dma-iommu.c 2019-11-17 23:47:30.0 +0100
+++ b/drivers/iommu/dma-iommu.c 2019-11-21 15:32:50.216488955 +0100
@@ -405,8 +405,7 @@ static dma_addr_t iommu_dma_alloc_iova(s
if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
iova_len = roundup_pow_of_two(iova_len);
- if (dev->bus_dma_mask)
- dma_limit &= dev->bus_dma_mask;
+ dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
if (domain->geometry.force_aperture)
dma_limit = min(dma_limit, domain->geometry.aperture_end);
diff -rupN a/drivers/of/device.c b/drivers/of/device.c
--- a/drivers/of/device.c 2019-11-17 23:47:30.0 +0100
+++ b/drivers/of/device.c 2019-11-21 15:32:50.216488955 +0100
@@ -93,7 +93,7 @@ int of_dma_configure(struct device *dev,
bool coherent;
unsigned long offset;
const struct iommu_ops *iommu;
- u64 mask;
+ u64 mask, end;
ret = of_dma_get_range(np, _addr, , );
if (ret < 0) {
@@ -148,12 +148,13 @@ int of_dma_configure(struct device *dev,
* Limit coherent and dma mask based on size and default mask
* set by the driver.
*/
- mask = DMA_BIT_MASK(ilog2(dma_addr + size - 1) + 1);
+ end = dma_addr + size - 1;
+ mask = DMA_BIT_MASK(ilog2(end) + 1);
dev->coherent_dma_mask &= mask;
*dev->dma_mask &= mask;
- /* ...but only set bus mask if we found valid dma-ranges earlier */
+ /* ...but only set bus limit if we found valid dma-ranges earlier */
if (!ret)
- dev->bus_dma_mask = mask;
+ dev->bus_dma_limit = end;
coherent = of_dma_is_coherent(np);
dev_dbg(dev, "device is%sdma coherent\n",
diff -rupN a/include/linux/device.h b/include/linux/device.h
--- a/include/linux/device.h 2019-11-17 23:47:30.0 +0100
+++ b/include/linux/device.h 2019-11-21 15:32:50.216488955 +0100
@@ -1186,8 +1186,8 @@ struct dev_links_info {
* @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
* hardware supports 64-bit addresses for consistent allocations
* such descriptors.
- * @bus_dma_mask: Mask of an upstream bridge or bus which imposes a smaller DMA
- * limit than the device itself supports.
+ * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
+ * DMA limit than the device itself supports.
* @dma_pfn_offset: offset of DMA memory range relatively
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 21/11/2019 12:21 pm, Christian Zigotzky wrote: On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote: On 21 November 2019 at 08:29 am, Christoph Hellwig wrote: On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote: /* * DMA addressing mode. * * 0 : 32 bit addressing for all chips. * 1 : 40 bit addressing when supported by chip. * 2 : 64 bit addressing when supported by chip, * limited to 16 segments of 4 GB -> 64 GB max. */ #define SYM_CONF_DMA_ADDRESSING_MODE CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE Cyrus config: CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 I will configure “0 : 32 bit addressing for all chips” for the RC8. Maybe this is the solution. 0 means you are going to do bounce buffering a lot, which seems generally like a bad idea. But why are we talking about the sym53c8xx driver now? The last issue you reported was about video4linux allocations. Both drivers have the same problem. They don't work if we have more than 3.5GB RAM. I try to find a solution until you have a good solution. I have already a solution for V4L but I still need one for the sym53c8xx driver. OK, you mean that "0" is a bad idea but maybe it works until you have a solution. ;-) Is this on the same machine with the funny non-power-of-two bus_dma_mask as your other report? If so, does Nicolas' latest patch[1] help at all? Robin. [1] https://lore.kernel.org/linux-iommu/20191121092646.8449-1-nsaenzjulie...@suse.de/T/#u
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 21 November 2019 at 01:16 pm, Christian Zigotzky wrote: On 21 November 2019 at 08:29 am, Christoph Hellwig wrote: On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote: /* * DMA addressing mode. * * 0 : 32 bit addressing for all chips. * 1 : 40 bit addressing when supported by chip. * 2 : 64 bit addressing when supported by chip, * limited to 16 segments of 4 GB -> 64 GB max. */ #define SYM_CONF_DMA_ADDRESSING_MODE CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE Cyrus config: CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 I will configure “0 : 32 bit addressing for all chips” for the RC8. Maybe this is the solution. 0 means you are going to do bounce buffering a lot, which seems generally like a bad idea. But why are we talking about the sym53c8xx driver now? The last issue you reported was about video4linux allocations. Both drivers have the same problem. They don't work if we have more than 3.5GB RAM. I try to find a solution until you have a good solution. I have already a solution for V4L but I still need one for the sym53c8xx driver. OK, you mean that "0" is a bad idea but maybe it works until you have a solution. ;-)
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On 21 November 2019 at 08:29 am, Christoph Hellwig wrote: On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote: /* * DMA addressing mode. * * 0 : 32 bit addressing for all chips. * 1 : 40 bit addressing when supported by chip. * 2 : 64 bit addressing when supported by chip, * limited to 16 segments of 4 GB -> 64 GB max. */ #define SYM_CONF_DMA_ADDRESSING_MODE CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE Cyrus config: CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 I will configure “0 : 32 bit addressing for all chips” for the RC8. Maybe this is the solution. 0 means you are going to do bounce buffering a lot, which seems generally like a bad idea. But why are we talking about the sym53c8xx driver now? The last issue you reported was about video4linux allocations. Both drivers have the same problem. They don't work if we have more than 3.5GB RAM. I try to find a solution until your have a good solution. I have already a solution for V4L but I still need one for the sym53c8xx driver.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
On Sat, Nov 16, 2019 at 08:06:05AM +0100, Christian Zigotzky wrote: > /* > * DMA addressing mode. > * > * 0 : 32 bit addressing for all chips. > * 1 : 40 bit addressing when supported by chip. > * 2 : 64 bit addressing when supported by chip, > * limited to 16 segments of 4 GB -> 64 GB max. > */ > #define SYM_CONF_DMA_ADDRESSING_MODE > CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE > > Cyrus config: > > CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 > > I will configure “0 : 32 bit addressing for all chips” for the RC8. Maybe > this is the solution. 0 means you are going to do bounce buffering a lot, which seems generally like a bad idea. But why are we talking about the sym53c8xx driver now? The last issue you reported was about video4linux allocations.
Re: Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
Hello, Kernel 5.4-rc5: Error message without limitation to 3.5G RAM: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 The kernel configured the bttv card for DMA in the upper region of RAM but the device believes that it only supports 32-bit addressing. The TV card works without the limitation to 3.5G RAM with the kernel 4.20.17. The issue has started with the PowerPC updates 4.21-1 [1] Cheers, Christian [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 > On 29. Oct 2019, at 05:49, Christian Zigotzky wrote: > > Hello, > > The bug with some PCI devices if you have more than 3.5G installed still > exist in the RC5. Could you please look in the following bug report. > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=205201 > > Thanks, > Christian
