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!
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED CC||mich...@ellerman.id.au -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 Roland (rj.ron...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #17 from Roland (rj.ron...@gmail.com) --- Kernel 5.5 alpha 1 fixed the issue with Dawicontrol DC-2976 UW SCSI board. Also a RTL 8169 ethernet card which had similar type of problem with earlier kernels works now with full (8 GB) Ram. -- You are receiving this mail because: You are watching the assignee of the bug.
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) [
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #16 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 286031 --> https://bugzilla.kernel.org/attachment.cgi?id=286031=edit dmesg of Christoph's Git kernel Christoph Hellwig wrote: 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, Here is the dmesg of your Git kernel. Thanks, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
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.
Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
FYI: Source files of the Dawicontrol DC 2976 UW SCSI board (PCI): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sym53c8xx_2?h=v5.4-rc7 /* * 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. > On 13. Nov 2019, at 12:02, Christoph Hellwig wrote: > > Interesting. Give me some time to come up with a real fix, as drivers > really should not mess with GFP flags for these allocations, and even > if they did swiotlb is supposed to take care of any resulting problems.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #15 from Christian Zigotzky (chzigot...@xenosoft.de) --- FYI: Souce files of the Dawicontrol DC 2976 UW SCSI board (PCI): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/sym53c8xx_2?h=v5.4-rc7 /* * 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. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #14 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 285889 --> https://bugzilla.kernel.org/attachment.cgi?id=285889=edit Patch for renaming the GFP_DMA32 to GFP_DMA Hi All, The issue with the BT878 TV cards is solved. :-) GFP_DMA32 was renamed to GFP_DMA in the PowerPC updates 4.21-1 in December last year. Some PCI devices still use GFP_DMA32 (grep -r GFP_DMA32 *). I renamed GFP_DMA32 to GFP_DMA in the file "drivers/media/v4l2-core/videobuf-dma-sg.c". After compiling the RC7 of kernel 5.4, my BT878 TV card works again. I created a patch for renaming GFP_DMA32 to GFP_DMA. This patch doesn't solve the issue with the Dawicontrol DC-2976 UW SCSI board. Please help us to solve the issue with the SCSI board too. Cheers, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #13 from Christian Zigotzky (chzigot...@xenosoft.de) --- Christoph, Now, I can definitely say that this patch does not solve the issue. Do you have another patch for testing or shall I bisect? Thanks, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #12 from Christian Zigotzky (chzigot...@xenosoft.de) --- Hi Christoph, I have seen that I have activated the kernel config option CONFIG_ARCH_DMA_ADDR_T_64BIT. That means your code in your patch won't work if this kernel option is enabled. +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT +/* Check if DMA address overflowed */ +if (min(addr, addr + size - 1) < +__phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) +return false; +#endif I will delete the lines with ifndef and endif and will try it again. Cheers, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #11 from Christian Zigotzky (chzigot...@xenosoft.de) --- Christoph, Do you have another patch for testing or shall I bisect? Thanks, Christian -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #10 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 285815 --> https://bugzilla.kernel.org/attachment.cgi?id=285815=edit Kernel 5.4-rc6 config for the Cyrus+ board and for the QEMU ppce500 board (CPU: P5040 and P5020) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #9 from Christian Zigotzky (chzigot...@xenosoft.de) --- Created attachment 285813 --> https://bugzilla.kernel.org/attachment.cgi?id=285813=edit dmesg fsl p5040 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #8 from Christian Zigotzky (chzigot...@xenosoft.de) --- Trace: [ 462.783184] Call Trace: [ 462.783187] [c001c6c67420] [c00b3358] .report_addr+0xb8/0xc0 (unreliable) [ 462.783192] [c001c6c67490] [c00b351c] .dma_direct_map_page+0xf0/0x128 [ 462.783195] [c001c6c67530] [c00b35b0] .dma_direct_map_sg+0x5c/0xac [ 462.783205] [c001c6c675e0] [80862e88] .__videobuf_iolock+0x660/0x6d8 [videobuf_dma_sg] [ 462.783220] [c001c6c676b0] [80854274] .videobuf_iolock+0x98/0xb4 [videobuf_core] [ 462.783271] [c001c6c67720] [808686e8] .buffer_prepare+0x150/0x268 [bttv] [ 462.783276] [c001c6c677c0] [80854afc] .videobuf_qbuf+0x2b8/0x428 [videobuf_core] [ 462.783288] [c001c6c67860] [80868f6c] .bttv_qbuf+0x50/0x64 [bttv] [ 462.783383] [c001c6c678e0] [807bf208] .v4l_qbuf+0x54/0x60 [videodev] [ 462.783402] [c001c6c67970] [807c1eac] .__video_do_ioctl+0x30c/0x3f8 [videodev] [ 462.783421] [c001c6c67a80] [807c3c08] .video_usercopy+0x18c/0x3dc [videodev] [ 462.783440] [c001c6c67c00] [807bb14c] .v4l2_ioctl+0x60/0x78 [videodev] [ 462.783460] [c001c6c67c90] [807d3c48] .v4l2_compat_ioctl32+0x9b4/0x1850 [videodev] [ 462.783468] [c001c6c67d70] [c01ad9cc] .__se_compat_sys_ioctl+0x284/0x127c [ 462.783473] [c001c6c67e20] [c67c] system_call+0x60/0x6c [ 462.783475] Instruction dump: [ 462.783477] 40fe0044 6000 892255d0 2f89 40fe0020 3c82ffc5 3921 6000 [ 462.783483] 38842029 992255d0 485ad0d9 6000 <0fe0> 38210070 e8010010 7c0803a6 [ 462.783490] ---[ end trace b677d4a00458e277 ]--- -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #7 from Christian Zigotzky (chzigot...@xenosoft.de) --- Unfortunately this patch doesn't solve the issue. Error message: [6.041163] bttv: driver version 0.9.19 loaded [6.041167] bttv: using 8 buffers with 2080k (520 pages) each for capture [6.041559] bttv: Bt8xx card found (0) [6.041609] bttv: 0: Bt878 (rev 17) at 1000:04:05.0, irq: 19, latency: 128, mmio: 0xc20001000 [6.041622] bttv: 0: using: Typhoon TView RDS + FM Stereo / KNC1 TV Station RDS [card=53,insmod option] [6.042216] bttv: 0: tuner type=5 [6.111994] bttv: 0: audio absent, no audio device found! [6.176425] bttv: 0: Setting PLL: 28636363 => 35468950 (needs up to 100ms) [6.25] bttv: PLL set ok [6.209351] bttv: 0: registered device video0 [6.211576] bttv: 0: registered device vbi0 [6.214897] bttv: 0: registered device radio0 [ 114.218806] bttv 1000:04:05.0: overflow 0xff507000+4096 of DMA mask bus mask df00 [ 114.218848] Modules linked in: rfcomm bnep tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb btrtl btbcm btintel bluetooth uio_pdrv_genirq uio ecdh_generic ecc [ 114.219012] [c001ecddf720] [808ff6e8] .buffer_prepare+0x150/0x268 [bttv] [ 114.219029] [c001ecddf860] [808fff6c] .bttv_qbuf+0x50/0x64 [bttv] -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #6 from Christian Zigotzky (chzigot...@xenosoft.de) --- FYI because of the issue with some PCI cards (SCSI, TV cards etc): Christoph Hellwig wrote: Can you send me the .config and a dmesg? And in the meantime try the patch below? >From 4d659b7311bd4141fdd3eeeb80fa2d7602ea01d4 Mon Sep 17 00:00:00 2001 From: Nicolas Saenz Julienne Date: Fri, 18 Oct 2019 13:00:43 +0200 Subject: dma-direct: check for overflows on 32 bit DMA addresses As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is possible for a device configured with 32 bit DMA addresses and a partial DMA mapping located at the end of the address space to overflow. It happens when a higher physical address, not DMAable, is translated to it's DMA counterpart. For example the Raspberry Pi 4, configurable up to 4 GB of memory, has an interconnect capable of addressing the lower 1 GB of physical memory with a DMA offset of 0xc000. It transpires that, any attempt to translate physical addresses higher than the first GB will result in an overflow which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne --- include/linux/dma-direct.h | 8 1 file changed, 8 insertions(+) diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h index adf993a3bd58..6ad9e9ea7564 100644 --- a/include/linux/dma-direct.h +++ b/include/linux/dma-direct.h @@ -3,6 +3,7 @@ #define _LINUX_DMA_DIRECT_H 1 #include +#include /* for min_low_pfn */ #include #ifdef CONFIG_ARCH_HAS_PHYS_TO_DMA @@ -27,6 +28,13 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size) if (!dev->dma_mask) return false; +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT +/* Check if DMA address overflowed */ +if (min(addr, addr + size - 1) < +__phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT))) +return false; +#endif + return addr + size - 1 <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask); } -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #5 from Christophe Leroy (christophe.le...@c-s.fr) --- I guess: git bisect bad 8d6973327 git bisect good v4.20 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #4 from Christian Zigotzky (chzigot...@xenosoft.de) --- Yes, I can. Could you please post the correct commits for starting bisect? git bisect start git bisect good ? git bisect bad ? Thanks -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 Christophe Leroy (christophe.le...@c-s.fr) changed: What|Removed |Added CC||christophe.le...@c-s.fr --- Comment #3 from Christophe Leroy (christophe.le...@c-s.fr) --- Can you bisect to identify the faulting commit ? -- You are receiving this mail because: You are watching the assignee of the bug.
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
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #2 from Christian Zigotzky (chzigot...@xenosoft.de) --- 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. -- You are receiving this mail because: You are watching the assignee of the bug.
Bug 205201 - Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
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
[Bug 205201] Booting halts if Dawicontrol DC-2976 UW SCSI board installed, unless RAM size limited to 3500M
https://bugzilla.kernel.org/show_bug.cgi?id=205201 --- Comment #1 from Christian Zigotzky (chzigot...@xenosoft.de) --- I have the same problem with my analog PCI TV card Typhoon TView RDS + FM Stereo (BT878 chip) in my AmigaOne X5000. It only works with reducing the mem size to 3500MB (mem=3500M). I figured out that the issue is somewhere in the PowerPC updates 4.21-1 [1]. Maybe the code change in the file "arch/powerpc/kernel/dma-swiotlb.c" [2] or maybe the change in the file "arch/powerpc/kernel/dma.c" [3]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/dma-swiotlb.c?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/dma.c?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 -- You are receiving this mail because: You are watching the assignee of the bug.
