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 <[email protected]> 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.
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.
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.
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. ;-)
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/[email protected]/T/#u
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/[email protected]/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
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?
On 21. Nov 2019, at 19:02, Christoph Hellwig <[email protected]> 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
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
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 0xffffffffUL
+#define ARCH_LOW_ADDRESS_LIMIT 0x0fffffffUL
#endif
phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
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 = 0xffffffffUL;
+#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 = 0x0fffffffUL;
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 0xffffffffUL
> +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffffffUL
> #endif
>
> phys_addr_t memblock_phys_alloc_range(phys_addr_t size, phys_addr_t align,
--
Sincerely yours,
Mike.
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 0xffffffffUL
> +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffffffUL
> #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
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 = 0xffffffffUL;
> +#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 = 0x0fffffffUL;
> 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 0xffffffffUL
>> +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffffffUL
>> #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
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 = 0xffffffffUL;
> +#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 = 0x0fffffffUL;
> 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
<asm/dma.h>" 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 = 0x0fffffffUL;
^~~~~~~~~~~~~~~~~~
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
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 0xffffffffUL
> +#define ARCH_LOW_ADDRESS_LIMIT 0x0fffffffUL
> #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
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!
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.
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.
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
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.
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 <[email protected]> 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.
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&p=49603&sid=1adf9e6d558c136c1ad4ff15c44212ba#p49599
[2] https://bugzilla.kernel.org/show_bug.cgi?id=205201
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!