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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi All, We still have some issues with PCI cards in our FSL P5020 and P5040 systems since the DMA mapping updates. [1, 2] We have to limit the RAM to 3500MB for some problematic PCI cards. (kernel boot argument 'mem=3500M') The problematic DMA mapping code was added with the PowerPC updates 4.21-1 to the official kernel source code last year. [3] We have created a bug report. [4] The old 4.x kernels aren't affected because they use the old DMA code. Please check the new DMA code again. Thanks, Christian [1] http://forum.hyperion-entertainment.com/viewtopic.php?f=58=49486#p49486 [2] http://forum.hyperion-entertainment.com/viewtopic.php?f=58=4349=50#p49099 [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 [4] https://bugzilla.kernel.org/show_bug.cgi?id=205201 On 28 November 2018 at 4:55 pm, Christian Zigotzky wrote: On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. Please don't apply the new DMA mapping code if you don't be sure if it works on all supported PowerPC machines. Is the new DMA mapping code really necessary? It's not really nice, to rewrote code if the old code works perfect. We must not forget, that we work for the end users. Does the end user have advantages with this new code? Is it faster? The old code works without any problems. I am also worried about this code. How can I test this new DMA mapping code? Thanks ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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. ;-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Bug 205201 - overflow of DMA mask and bus mask
Hello Christoph, I have found the issue. :-) 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 TV card works again. Cheers, Christian On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote: On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote: Now, I can definitely say that this patch does not solve the issue. Do you have another patch for testing or shall I bisect? I'm still interested in the .config and dmesg. Especially if the board is using arch/powerpc/sysdev/fsl_pci.c, which is the only place inside the powerpc arch code doing funny things with the bus_dma_mask, which Robin pointed out looks fishy. Thanks, Christian ---end quoted text--- ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Bug 205201 - overflow of DMA mask and bus mask
On 12 November 2019 at 3:41 pm, Christoph Hellwig wrote: On Mon, Nov 11, 2019 at 01:22:55PM +0100, Christian Zigotzky wrote: Now, I can definitely say that this patch does not solve the issue. Do you have another patch for testing or shall I bisect? I'm still interested in the .config and dmesg. Especially if the board is using arch/powerpc/sysdev/fsl_pci.c, which is the only place inside the powerpc arch code doing funny things with the bus_dma_mask, which Robin pointed out looks fishy. Here you are: .config: https://bugzilla.kernel.org/attachment.cgi?id=285815 dmesg: https://bugzilla.kernel.org/attachment.cgi?id=285813 Thanks ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Bug 205201 - overflow of DMA mask and bus mask
On 11 November 2019 at 09:16 am, Christian Zigotzky wrote: On 11 November 2019 at 09:12 am, Christian Zigotzky wrote: On 10 November 2019 at 08:27 am, Christian Zigotzky wrote: On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote: On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. 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); } Hello Christoph, Thanks a lot for your patch! Unfortunately this patch doesn't solve the issue. Error messages: [ 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] - 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] [ 46
Re: Bug 205201 - overflow of DMA mask and bus mask
On 11 November 2019 at 09:12 am, Christian Zigotzky wrote: On 10 November 2019 at 08:27 am, Christian Zigotzky wrote: On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote: On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. 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); } Hello Christoph, Thanks a lot for your patch! Unfortunately this patch doesn't solve the issue. Error messages: [ 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] - 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
Re: Bug 205201 - overflow of DMA mask and bus mask
On 10 November 2019 at 08:27 am, Christian Zigotzky wrote: On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: On 05 November 2019 at 05:28 pm, Christoph Hellwig wrote: On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. 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); } Hello Christoph, Thanks a lot for your patch! Unfortunately this patch doesn't solve the issue. Error messages: [ 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] - 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]
Re: Bug 205201 - overflow of DMA mask and bus mask
On 07 November 2019 at 10:53 am, Christian Zigotzky wrote: On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote: On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. 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); } Hello Christoph, Thanks a lot for your patch! Unfortunately this patch doesn't solve the issue. Error messages: [ 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] - 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] [c001
Re: Bug 205201 - overflow of DMA mask and bus mask
On 05 November 2019 at 5:28 pm, Christoph Hellwig wrote: On Tue, Nov 05, 2019 at 08:56:27AM +0100, Christian Zigotzky wrote: Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. 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); } Hello Christoph, Thanks a lot for your patch! Unfortunately this patch doesn't solve the issue. Error messages: [ 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] - 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]
Bug 205201 - overflow of DMA mask and bus mask
Hi All, We still have DMA problems with some PCI devices. Since the PowerPC updates 4.21-1 [1] we need to decrease the RAM to 3500MB (mem=3500M) if we want to work with our PCI devices. The FSL P5020 and P5040 have these problems currently. Error message: [ 25.654852] bttv 1000:04:05.0: overflow 0xfe077000+4096 of DMA mask bus mask df00 All 5.x Linux kernels can't initialize a SCSI PCI card anymore so booting of a Linux userland isn't possible. PLEASE check the DMA changes in the PowerPC updates 4.21-1 [1]. The kernel 4.20 works with all PCI devices without limitation of RAM. We created a bug report a month ago. [2] Thanks, Christian [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d6973327ee84c2f40dd9efd8928d4a1186c96e2 [2] https://bugzilla.kernel.org/show_bug.cgi?id=205201 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 12 February 2019 at 8:31PM, Christian Zigotzky wrote:
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!
I also tested it in a virtual e5500 QEMU machine today.
Unfortunately the
kernel crashes.
This looks like a patch I fixed in mainline a while ago, but which
the powerpc tree didn't have yet.
I've cherry picked this commit
("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
and added it to the powerpc-dma.6 tree, please retry with that one.
Hello Christoph,
Have you added it to the powerpc-dma.6 tree yet? The last commit was
4 days
ago.
I added it, but forgot to push it out. It is there now, sorry:
http://git.infradead.org/users/hch/misc.git/commitdiff/2cf0745b7420af4a3e871d5a970a45662dfae69c
Hi Christoph
Many thanks! Your Git kernel works in a virtual e5500 machine now! :-)
I think we have reached the end of testing! All things are working
with your DMA updates.
I am looking forward to testing your DMA changes in the next merge
window again. :-)
Cheers
Christian
Edit: typo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 12 February 2019 at 4:25PM, Christoph Hellwig wrote:
On Tue, Feb 12, 2019 at 01:42:56PM +0100, Christian Zigotzky wrote:
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!
I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
kernel crashes.
This looks like a patch I fixed in mainline a while ago, but which
the powerpc tree didn't have yet.
I've cherry picked this commit
("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
and added it to the powerpc-dma.6 tree, please retry with that one.
Hello Christoph,
Have you added it to the powerpc-dma.6 tree yet? The last commit was 4 days
ago.
I added it, but forgot to push it out. It is there now, sorry:
http://git.infradead.org/users/hch/misc.git/commitdiff/2cf0745b7420af4a3e871d5a970a45662dfae69c
Hi Christoph
Many thanks! Your Git kernel works in a virtual e5500 machine now! :-)
I think we have reached the end of testing! All things are working with
your DMA updates.
I am looking forward to test your DMA changes in the next merge window
again. :-)
Cheers
Christian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 11 February 2019 at 08:38AM, Christoph Hellwig wrote:
On Sun, Feb 10, 2019 at 01:00:20PM +0100, Christian Zigotzky wrote:
I tested the whole series today. The kernels boot and the P.A. Semi
Ethernet works! :-) Thanks a lot!
I also tested it in a virtual e5500 QEMU machine today. Unfortunately the
kernel crashes.
This looks like a patch I fixed in mainline a while ago, but which
the powerpc tree didn't have yet.
I've cherry picked this commit
("swiotlb: clear io_tlb_start and io_tlb_end in swiotlb_exit")
and added it to the powerpc-dma.6 tree, please retry with that one.
Hello Christoph,
Have you added it to the powerpc-dma.6 tree yet? The last commit was 4
days ago.
Thanks,
Christian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, Mario successfully tested a kernel from your Git [1] on his T2080rdb today. Link to the log: https://gitlab.com/oshw-powerpc-notebook/T2080customizations/blob/master/kernel/dma_fix/kernel_dma_fix_log.txt He wrote: Please, note that all of the above kernel runs just fine with the T2080rdb, however did not had the time to test extensively (tested: login into MATE graphical desktop environment, used ArctiFox for opening couple of websites, then played Neverball). —— Cheers, Christian [1] http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, Mario successfully tested a kernel from your Git [1] on his T2080rdb today. Link to the log: https://gitlab.com/oshw-powerpc-notebook/T2080customizations/blob/master/kernel/dma_fix/kernel_dma_fix_log.txt He wrote: Please, note that all of the above kernel runs just fine with the T2080rdb, however did not had the time to test extensively (tested: login into MATE graphical desktop environment, used ArctiFox for opening couple of websites, then played Neverball). —— Cheers, Christian [1] http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, On 08 February 2019 at 10:18AM, Christoph Hellwig wrote: On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote: Hi Christoph, Your new patch fixes the problems with the P.A. Semi Ethernet! :-) Thanks a lot once again for testing! Now can you test with this patch and the whole series? I've updated the powerpc-dma.6 branch to include this fix. I tested the whole series today. The kernels boot and the P.A. Semi Ethernet works! :-) Thanks a lot! I also tested it in a virtual e5500 QEMU machine today. Unfortunately the kernel crashes. Log: [ 54.624330] BUG: Unable to handle kernel data access at 0xc06c008a0013014a [ 54.625640] Faulting instruction address: 0xc0027e7c [ 54.626140] Oops: Kernel access of bad area, sig: 11 [#1] [ 54.626456] BE SMP NR_CPUS=4 QEMU e500 [ 54.626876] Modules linked in: [ 54.627284] CPU: 1 PID: 1876 Comm: systemd-journal Not tainted 5.0.0-rc5-DMA_A1-X5000-54581-gda1d065-dirty #1 [ 54.627819] NIP: c0027e7c LR: c00b5264 CTR: [ 54.628173] REGS: c0007ffeb700 TRAP: 0300 Not tainted (5.0.0-rc5-DMA_A1-X5000-54581-gda1d065-dirty) [ 54.628607] MSR: 80009000 CR: 44008486 XER: [ 54.629023] DEAR: c06c008a0013014a ESR: 0080 IRQMASK: 0 [ 54.629023] GPR00: 5254 c0007ffeb990 c16b2000 c06c008a0013014a [ 54.629023] GPR04: c0007c54f8c0 0058 0006 [ 54.629023] GPR08: 7c54f8c0 006c008a0013014a c0007c86c000 [ 54.629023] GPR12: 28002482 c00038c0 c00078dfaa70 [ 54.629023] GPR16: c00078366c00 005e [ 54.629023] GPR20: c0007c54f8c0 0007 c00078dfa000 [ 54.629023] GPR24: 0047 803f6470 [ 54.629023] GPR28: c0007928d470 c00078801dc0 005e c00078dfa7c0 [ 54.632572] NIP [c0027e7c] .memcpy+0x1fc/0x288 [ 54.632886] LR [c00b5264] .swiotlb_tbl_sync_single+0xb0/0xe4 [ 54.633221] Call Trace: [ 54.633513] [c0007ffeb990] [c0007ffeba70] 0xc0007ffeba70 (unreliable) [ 54.633988] [c0007ffeba00] [c00b41e4] .dma_direct_sync_single_for_cpu+0x58/0x6c [ 54.634436] [c0007ffeba70] [c0788da4] .e1000_clean_rx_irq+0x1bc/0x4c8 [ 54.634857] [c0007ffebb90] [c078667c] .e1000_clean+0x714/0x8d4 [ 54.635263] [c0007ffebcc0] [c0a3f15c] .net_rx_action+0x11c/0x2a4 [ 54.635712] [c0007ffebdb0] [c0c48c20] .__do_softirq+0x150/0x2a8 [ 54.636211] [c0007ffebeb0] [c0064184] .irq_exit+0x6c/0xc4 [ 54.636533] [c0007ffebf20] [c0004124] .__do_irq+0x80/0x94 [ 54.636985] [c0007ffebf90] [c000eca0] .call_do_irq+0x14/0x24 [ 54.637371] [c0007c86fd80] [c00041c0] .do_IRQ+0x88/0xc4 [ 54.637737] [c0007c86fe20] [c0012920] exc_0x500_common+0xd8/0xdc [ 54.638104] Instruction dump: [ 54.638451] e861fff8 4e800020 7cd01120 7ca62850 38e0 28a50010 409f0010 8804 [ 54.638887] 9803 38e70001 409e0010 7c07222e <7c071b2e> 38e70002 409d000c 7c07202e [ 54.639594] ---[ end trace a4861de7e4c199f7 ]--- [ 54.639873] [ 55.640484] Kernel panic - not syncing: Aiee, killing interrupt handler! [ 55.641556] Rebooting in 180 seconds.. - I tested with the following QEMU commands: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -nographic -kernel /home/christian/Downloads/vmlinux-5.0-rc5-2-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-5.0 -nic user,model=e1000 -drive format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio -append "rw root=/dev/vda" -smp 4 ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel /home/christian/Downloads/vmlinux-5.0-rc5-2-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-5.0 -drive format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio -nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw es1370 -smp 4 The RC5 of kernel 5.0 boots without any problems in this virtual machine. Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
OK, I will test it. — Christian Sent from my iPhone > On 8. Feb 2019, at 10:18, Christoph Hellwig wrote: > >> On Fri, Feb 08, 2019 at 10:01:46AM +0100, Christian Zigotzky wrote: >> Hi Christoph, >> >> Your new patch fixes the problems with the P.A. Semi Ethernet! :-) > > Thanks a lot once again for testing! > > Now can you test with this patch and the whole series? > > I've updated the powerpc-dma.6 branch to include this fix. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph,
Your new patch fixes the problems with the P.A. Semi Ethernet! :-)
Thanks,
Christian
On 07 February 2019 at 05:34AM, Christian Zigotzky wrote:
Hi Christoph,
I also didn’t notice the 32-bit DMA mask in your patch. I have to read your
patches and descriptions carefully in the future. I will test your new patch at
the weekend.
Thanks,
Christian
Sent from my iPhone
On 6. Feb 2019, at 16:16, Christoph Hellwig wrote:
On Wed, Feb 06, 2019 at 04:15:05PM +0100, Christoph Hellwig wrote:
The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
remember correctly. powerpc/dma: use the dma_direct mapping routines
was the one that you said makes the pasemi ethernet stop working.
Can you post the dmesg from the failing runs?
But I just noticed I sent you a wrong patch - the pasemi ethernet
should set a 64-bit DMA mask, not 32-bit. Updated version below,
32-bit would just keep the previous status quo.
commit 6c8f88045dee3597b9ce2ea5371eee37073a
Author: Christoph Hellwig
Date: Mon Feb 4 13:38:22 2019 +0100
pasemi WIP
diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c
b/drivers/net/ethernet/pasemi/pasemi_mac.c
index 8a31a02c9f47..2d7d1589490a 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
err = -ENODEV;
goto out;
}
+dma_set_mask(>dma_pdev->dev, DMA_BIT_MASK(64));
mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
if (!mac->iob_pdev) {
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph,
I also didn’t notice the 32-bit DMA mask in your patch. I have to read your
patches and descriptions carefully in the future. I will test your new patch at
the weekend.
Thanks,
Christian
Sent from my iPhone
> On 6. Feb 2019, at 16:16, Christoph Hellwig wrote:
>
>> On Wed, Feb 06, 2019 at 04:15:05PM +0100, Christoph Hellwig wrote:
>> The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
>> ("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
>> remember correctly. powerpc/dma: use the dma_direct mapping routines
>> was the one that you said makes the pasemi ethernet stop working.
>>
>> Can you post the dmesg from the failing runs?
>
> But I just noticed I sent you a wrong patch - the pasemi ethernet
> should set a 64-bit DMA mask, not 32-bit. Updated version below,
> 32-bit would just keep the previous status quo.
>
> commit 6c8f88045dee3597b9ce2ea5371eee37073a
> Author: Christoph Hellwig
> Date: Mon Feb 4 13:38:22 2019 +0100
>
>pasemi WIP
>
> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c
> b/drivers/net/ethernet/pasemi/pasemi_mac.c
> index 8a31a02c9f47..2d7d1589490a 100644
> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
> @@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>err = -ENODEV;
>goto out;
>}
> +dma_set_mask(>dma_pdev->dev, DMA_BIT_MASK(64));
>
>mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
>if (!mac->iob_pdev) {
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 04 February 2019 at 01:38PM, Christoph Hellwig wrote:
It seems like the pasemi driver fails to set a DMA mask, but seems
otherwise 64-bit DMA capable. The old PPC code didn't verify the
dma mask during the map operations, but the x86-derived generic
code does.
This patch just sets the DMA mask.
Olof: does this look ok? The DMA device seems to not directly
bound by the net driver, but not really used by anything else in tree
either..
diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c
b/drivers/net/ethernet/pasemi/pasemi_mac.c
index d21041554507..d98bd447c536 100644
--- a/drivers/net/ethernet/pasemi/pasemi_mac.c
+++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
@@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
err = -ENODEV;
goto out;
}
+ dma_set_mask(>dma_pdev->dev, DMA_BIT_MASK(32));
mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
if (!mac->iob_pdev) {
Hello Christoph,
I patched the source code from the Git 'powerpc-dma.6' with your patch
today. Unfortunately the P.A. Semi Ethernet doesn't work with the
patched Git kernel.
After that I tried it with the patch applied over the working setup
again (powerpc/dma: use the dma_direct mapping routines). Unfortunately
after compiling
and booting, the P.A. Semi Ethernet doesn't work either.
Cheers,
Christian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 04 February 2019 at 08:56AM, Christoph Hellwig wrote: On Sun, Feb 03, 2019 at 05:49:02PM +0100, Christian Zigotzky wrote: OK, next step: b50f42f0fe12965ead395c76bcb6a14f00cdf65b (powerpc/dma: use the dma_direct mapping routines) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout b50f42f0fe12965ead395c76bcb6a14f00cdf65b Results: The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't work. Are there any interesting messages in the boot log? Can you send me the dmesg? Here you are: http://www.xenosoft.de/dmesg_X1000_with_DMA_updates.txt -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I will try it at the weekend. Thanks, Christian Sent from my iPhone > On 1. Feb 2019, at 09:04, Christoph Hellwig wrote: > >> On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote: >> Hi Christoph, >> >> I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6' >> today. >> >> Gitweb: >> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 >> >> git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a >> >> The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't >> work. > > Oh. Can you try with just the next one and then two patches applied > over the working setup? That is first: > > http://git.infradead.org/users/hch/misc.git/commitdiff/b50f42f0fe12965ead395c76bcb6a14f00cdf65b > > then also with: > > http://git.infradead.org/users/hch/misc.git/commitdiff/21fe52470a483afbb1726741118abef8602dde4d ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6' today. Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a The X1000 and X5000 boot but unfortunately the P.A. Semi Ethernet doesn't work. Error messages (X1000): [ 17.371736] pci :00:1a.0: overflow 0x0002691bf802+1646 of DMA mask bus mask 0 [ 17.371760] WARNING: CPU: 0 PID: 2496 at kernel/dma/direct.c:43 .dma_direct_map_page+0x11c/0x200 [ 17.371762] Modules linked in: [ 17.371769] CPU: 0 PID: 2496 Comm: NetworkManager Not tainted 5.0.0-rc4-3_A-EON_AmigaOne_X1000_Nemo-54580-g8d7a724-dirty #2 [ 17.371772] NIP: c010395c LR: c0103a30 CTR: c0726f70 [ 17.371775] REGS: c0026900e9a0 TRAP: 0700 Not tainted (5.0.0-rc4-3_A-EON_AmigaOne_X1000_Nemo-54580-g8d7a724-dirty) [ 17.371777] MSR: 90029032 CR: 2400 XER: 2000 [ 17.371786] IRQMASK: 0 GPR00: c0103a30 c0026900ec30 c1923f00 0052 GPR04: c0026f206778 c0026f20d458 0346 GPR08: 0007 0010 GPR12: 22002444 c1b1 GPR16: 10382410 c0026bd9d820 GPR20: c0026919c000 GPR24: 0800 c0026919 c002692a4180 c0026919 GPR28: c00277ada1c8 066e c0026d3c68b0 0802 [ 17.371823] NIP [c010395c] .dma_direct_map_page+0x11c/0x200 [ 17.371827] LR [c0103a30] .dma_direct_map_page+0x1f0/0x200 [ 17.371829] Call Trace: [ 17.371833] [c0026900ec30] [c0103a30] .dma_direct_map_page+0x1f0/0x200 (unreliable) [ 17.371840] [c0026900ecd0] [c099b7ec] .pasemi_mac_replenish_rx_ring+0x12c/0x2a0 [ 17.371846] [c0026900eda0] [c099dc64] .pasemi_mac_open+0x384/0x7c0 [ 17.371853] [c0026900ee40] [c0c6f484] .__dev_open+0x134/0x1e0 [ 17.371858] [c0026900eee0] [c0c6f9ec] .__dev_change_flags+0x1bc/0x210 [ 17.371863] [c0026900ef90] [c0c6fa88] .dev_change_flags+0x48/0xa0 [ 17.371869] [c0026900f030] [c0c8c88c] .do_setlink+0x3dc/0xf60 [ 17.371875] [c0026900f1b0] [c0c8dd84] .__rtnl_newlink+0x5e4/0x900 [ 17.371880] [c0026900f5f0] [c0c8e10c] .rtnl_newlink+0x6c/0xb0 [ 17.371885] [c0026900f680] [c0c89838] .rtnetlink_rcv_msg+0x2e8/0x3d0 [ 17.371891] [c0026900f760] [c0cc0f90] .netlink_rcv_skb+0x120/0x170 [ 17.371896] [c0026900f820] [c0c87318] .rtnetlink_rcv+0x28/0x40 [ 17.371901] [c0026900f8a0] [c0cc03f8] .netlink_unicast+0x208/0x2f0 [ 17.371906] [c0026900f950] [c0cc09a8] .netlink_sendmsg+0x348/0x460 [ 17.371911] [c0026900fa30] [c0c38774] .sock_sendmsg+0x44/0x70 [ 17.371915] [c0026900fab0] [c0c3a79c] .___sys_sendmsg+0x30c/0x320 [ 17.371920] [c0026900fca0] [c0c3c3b4] .__sys_sendmsg+0x74/0xf0 [ 17.371926] [c0026900fd90] [c0cb4da0] .__se_compat_sys_sendmsg+0x40/0x60 [ 17.371932] [c0026900fe20] [c000a21c] system_call+0x5c/0x70 [ 17.371934] Instruction dump: [ 17.371937] 6000 f8610070 3d20 6129fffe 79290020 e8e7 7fa74840 409d00b8 [ 17.371946] 3d420001 892acb59 2f89 419e00b8 <0fe0> 382100a0 3860 e8010010 [ 17.371954] ---[ end trace a81f3c344f625f76 ]--- [ 17.396654] IPv6: ADDRCONF(NETDEV_UP): enp0s20f3: link is not ready Additionally, Xorg doesn't start on a virtual e5500 QEMU machine anymore. I tested with the following QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel /home/christian/Downloads/vmlinux-5.0-rc4-3-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-5.0 -drive format=raw,file=/home/christian/Downloads/Fienix-Beta120418.img,index=0,if=virtio -nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw es1370 -smp 4 Cheers, Christian On 30 January 2019 at 05:40AM, Christian Zigotzky wrote: Hi Christoph, Thanks a lot for the updates. I will test the full branch tomorrow. Cheers, Christian Sent from my iPhone On 29. Jan 2019, at 17:34, Christoph Hellwig wrote: On Tue, Jan 29, 2019 at 05:14:11PM +0100, Christoph Hellwig wrote: On Tue, Jan 29, 2019 at 04:03:32PM +0100, Christian Zigotzky wrote: Hi Christoph, I compiled kernels for the X5000 and X1000 from your new branch 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet works! Thanks for testing! I'll prepare a new
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, Thanks a lot for the updates. I will test the full branch tomorrow. Cheers, Christian Sent from my iPhone > On 29. Jan 2019, at 17:34, Christoph Hellwig wrote: > >> On Tue, Jan 29, 2019 at 05:14:11PM +0100, Christoph Hellwig wrote: >>> On Tue, Jan 29, 2019 at 04:03:32PM +0100, Christian Zigotzky wrote: >>> Hi Christoph, >>> >>> I compiled kernels for the X5000 and X1000 from your new branch >>> 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet >>> works! >> >> Thanks for testing! I'll prepare a new series that adds the other >> patches on top of this one. > > And that was easier than I thought - we just had a few patches left > in powerpc-dma.6, so I've rebased that branch on top of > powerpc-dma.6-debug.2: > >git://git.infradead.org/users/hch/misc.git powerpc-dma.6 > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 > > I hope the other patches are simple enough, so just testing the full > branch checkout should be fine for now. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I compiled kernels for the X5000 and X1000 from your new branch 'powerpc-dma.6-debug.2' today. The kernels boot and the P.A. Semi Ethernet works! Cheers, Christian On 28 January 2019 at 5:52PM, Christian Zigotzky wrote: Thanks a lot! I will test it tomorrow. — Christian Sent from my iPhone On 28. Jan 2019, at 17:22, Christoph Hellwig wrote: On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote: On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote: Christoph, What shall I do next? I'll need to figure out what went wrong with the new zone selection on powerpc and give you another branch to test. Can you try the new powerpc-dma.6-debug.2 branch: git://git.infradead.org/users/hch/misc.git powerpc-dma.6-debug.2 Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Thanks a lot! I will test it tomorrow. — Christian Sent from my iPhone > On 28. Jan 2019, at 17:22, Christoph Hellwig wrote: > >> On Mon, Jan 28, 2019 at 08:04:22AM +0100, Christoph Hellwig wrote: >>> On Sun, Jan 27, 2019 at 02:13:09PM +0100, Christian Zigotzky wrote: >>> Christoph, >>> >>> What shall I do next? >> >> I'll need to figure out what went wrong with the new zone selection >> on powerpc and give you another branch to test. > > Can you try the new powerpc-dma.6-debug.2 branch: > >git://git.infradead.org/users/hch/misc.git powerpc-dma.6-debug.2 > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Christoph, What shall I do next? Cheers, Christian On 25 January 2019 at 2:37PM, Christian Zigotzky wrote: Next step just with the first patch: 5c532d07c2f3c3972104de505d06b8d85f403f06 (use powerpc zone selection) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6-debug a git checkout 5c532d07c2f3c3972104de505d06b8d85f403f06 Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug Results: X5000: The kernel detects the SATA hard disk drive and boots without any problems. X1000: The kernel boots and the P.A. Semi Ethernet works! -- Christian On 23 January 2019 at 3:34PM, Christian Zigotzky wrote: Hi Christoph, I also compiled a kernel (zImage) for the X1000 from your Git 'powerpc-dma.6-debug' (both patches) today. It boots and the P.A. Semi Ethernet works! I will test just the first patch tomorrow. Thanks, Christian On 21 January 2019 at 3:38PM, Christian Zigotzky wrote: Hello Christoph, Thanks for your reply. I successfully compiled a kernel (uImage) for the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today. It detects the SATA hard disk drive and boots without any problems. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step just with the first patch: 5c532d07c2f3c3972104de505d06b8d85f403f06 (use powerpc zone selection) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6-debug a git checkout 5c532d07c2f3c3972104de505d06b8d85f403f06 Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6-debug Results: X5000: The kernel detects the SATA hard disk drive and boots without any problems. X1000: The kernel boots and the P.A. Semi Ethernet works! -- Christian On 23 January 2019 at 3:34PM, Christian Zigotzky wrote: Hi Christoph, I also compiled a kernel (zImage) for the X1000 from your Git 'powerpc-dma.6-debug' (both patches) today. It boots and the P.A. Semi Ethernet works! I will test just the first patch tomorrow. Thanks, Christian On 21 January 2019 at 3:38PM, Christian Zigotzky wrote: Hello Christoph, Thanks for your reply. I successfully compiled a kernel (uImage) for the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today. It detects the SATA hard disk drive and boots without any problems. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I also compiled a kernel (zImage) for the X1000 from your Git 'powerpc-dma.6-debug' (both patches) today. It boots and the P.A. Semi Ethernet works! I will test just the first patch tomorrow. Thanks, Christian On 21 January 2019 at 3:38PM, Christian Zigotzky wrote: Hello Christoph, Thanks for your reply. I successfully compiled a kernel (uImage) for the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today. It detects the SATA hard disk drive and boots without any problems. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hello Christoph, Thanks for your reply. I successfully compiled a kernel (uImage) for the X5000 from your Git 'powerpc-dma.6-debug' (both patches) today. It detects the SATA hard disk drive and boots without any problems. I will test the first patch in next days. Thanks for your help, Christian On 19 January 2019 at 3:04PM, Christoph Hellwig wrote: On Sat, Jan 19, 2019 at 02:02:22PM +0100, Christoph Hellwig wrote: Interesting. This suggest it is related to the use of ZONE_DMA by the FSL SOCs that your board uses. Let me investigate this a bit more. As a hack to check that theory I've pushed a new commit to the powerpc-dma.6-debug branch to use old powerpc GFP_DMA selection with the new dma direct code: http://git.infradead.org/users/hch/misc.git/commitdiff/5c532d07c2f3c3972104de505d06b8d85f403f06 And another one that drops the addressability checks that powerpc never had: http://git.infradead.org/users/hch/misc.git/commitdiff/18e7629b38465ca98f8e7eed639123a13ac3b669 Can you first test with both patches, and then just with the first in case that worked? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I have found a small workaround. If I add 'mem=3500M' to the boot arguments then it detects the SATA hard disk and boots without any problems. X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 mem=3500M Cheers, Christian On 19 January 2019 at 12:40PM, Christian Zigotzky wrote: Hi Christoph, I bought a USB null modem RS-232 serial cable today so I was able to get some SATA error messages. Error messages: [ 13.468538] fsl-sata ffe22.sata: Sata FSL Platform/CSB Driver init [ 13.475106] fsl-sata ffe22.sata: failed to start port 0 (errno=-12) [ 13.481736] fsl-sata ffe221000.sata: Sata FSL Platform/CSB Driver init [ 13.488267] fsl-sata ffe221000.sata: failed to start port 0 (errno=-12) --- errno=-12 = Out of memory Please find attached the complete serial log. Cheers, Christian On 18 January 2019 at 4:06PM, Christian Zigotzky wrote: Hello Christoph, I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your Git powerpc-dma.6-debug today. Unfortunately I don't see any error messages (kernel ring buffer) and I don't have a RS232 serial null modem cable to get them. Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, I bought a USB null modem RS-232 serial cable today so I was able to get some SATA error messages. Error messages: [ 13.468538] fsl-sata ffe22.sata: Sata FSL Platform/CSB Driver init [ 13.475106] fsl-sata ffe22.sata: failed to start port 0 (errno=-12) [ 13.481736] fsl-sata ffe221000.sata: Sata FSL Platform/CSB Driver init [ 13.488267] fsl-sata ffe221000.sata: failed to start port 0 (errno=-12) --- errno=-12 = Out of memory Please find attached the complete serial log. Cheers, Christian On 18 January 2019 at 4:06PM, Christian Zigotzky wrote: Hello Christoph, I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your Git powerpc-dma.6-debug today. Unfortunately I don't see any error messages (kernel ring buffer) and I don't have a RS232 serial null modem cable to get them. Cheers, Christian =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2019.01.19 12:21:05 =~=~=~=~=~=~=~=~=~=~=~= U-Boot 2014.04 (Oct 17 2016 - 08:22:22) CPU0: P5020, Version: 2.0, (0x82200020) Core: e5500, Version: 1.2, (0x80240012) Clock Configuration: CPU0:1995 MHz, CPU1:1995 MHz, CCB:798 MHz, DDR:665 MHz (1330 MT/s data rate) (Asynchronous), LBC:49.875 MHz FMAN1: 498.750 MHz QMAN: 399 MHz PME: 399 MHz L1:D-cache 32 KiB enabled I-cache 32 KiB enabled Reset Configuration Word (RCW): : 0c54 1e1e 0010: 44808c00 ff002000 6800 4500 0020: 0003000f 0030: a000 Board: CYRUS 36-bit Addressing I2C: ready SPI: ready DRAM: Initializingusing SPD Detected UDIMM KHX1600C10D3/4G Detected UDIMM KHX1600C10D3/4G Not enough bank(chip-select) for CS0+CS1 on controller 0, interleaving disabled! Not enough bank(chip-select) for CS0+CS1 on controller 1, interleaving disabled! 6 GiB left unmapped 8 GiB (DDR3, 64-bit, CL=9, ECC off) DDR Controller Interleaving Mode: cache line Local Bus Controller Registers BR0 0xE0001001 OR0 0xFFF00010 BR1 0xE1001001 OR1 0xFFF00010 BR2 0x OR2 0x BR3 0x OR3 0x BR4 0x OR4 0x BR5 0x OR5 0x BR6 0x OR6 0x BR7 0x OR7 0x LBCR 0x4000 LCRR 0x80010004 L2:512 KiB enabled Corenet Platform Cache: 2 MiB enabled SERDES: bank 2 disabled MMC: FSL_SDHC: 0 EEPROM: NXID v0 PCIe1: Root Complex, x4 gen2, regs @ 0xfe20 01:00.0 - 1002:9440 - Display controller PCIe1: Bus 00 - 01 PCIe2: Root Complex, x4 gen2, regs @ 0xfe201000 03:00.0 - 111d:8092 - Bridge device 04:01.0- 111d:8092 - Bridge device 05:00.0 - 12d8:e111 - Bridge device 06:04.0 - 10ec:8139 - Network controller 06:05.0 - 109e:036e - Multimedia device 06:05.1 - 109e:0878 - Multimedia device 04:02.0- 111d:8092 - Bridge device 04:03.0- 111d:8092 - Bridge device 04:08.0- 111d:8092 - Bridge device 04:10.0- 111d:8092 - Bridge device PCIe2: Bus 02 - 0a PCIe3: disabled PCIe4: disabled Looking for VGA PINS: 0xfc000808 videoboot: Booting PCI video card bus 1, function 0, device 0 Begin BIOS POST End BIOS POST Setting VESA Mode Found required VESA mode About to set mode 279 About to get mode Got mode 49431 (0xc117) OK XSize = 1024 YSize = 768 Base =0xe000 mmio_base = 0x8000 bgx = 0xad55ad55 fgx = 0x0 In:serial Out: serial Err: serial ID: NXID v0 SN: 116330018 UID: 442943100191005198d3a080a080 Errata: ÿ "8 Build date: 2015/09/22 10:38:00 CRC: d4925668 SCSI: scanning bus for devices... Found 0 device(s). Net: Initializing Fman MMC read: dev # 0, block # 1130, count 128 ... Fman1: Uploading microcode version 106.1.0 Tuning PHY @ 3 Tuning PHY @ 7 FM1@DTSEC4 [PRIME], FM1@DTSEC5 MMC read: dev # 0, block # 1280, count 512 ... 512 blocks read: OK MMC read: dev # 0, block # 65536, count 131072 ... 131072 blocks read: OK USB0: USB EHCI 1.00 scanning bus 0 for devices... 5 USB Device(s) found USB1: USB EHCI 1.00 scanning bus 1 for devices... ERROR: Invalid USB EP length (9) ERROR: Invalid USB EP length (9) ERROR: Invalid USB EP length (9) 4 USB Device(s) found Timeout poll on interrupt endpoint Failed to get keyboard state from device 0c45:5303 SATA0 (3 Gbps) SATA1 (No RDY) scanning bus for devices... Found 0 device(s). X5000> setenv bootargs root=/dev/sda2 console=ttyS0,115200 X5000> load sata 0:1 100 uImage-5.0 reading uImage-5.0 10687255 bytes read in 75 ms (135.9 MiB/s) X5000> iminfo ## Checking Image at 0100 ... Legacy image found Image Name: Linux-5.0.0-rc2-2_A-EON_A1-X5000 Created: 2019-01-18 14:47:06 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:10687191 Bytes = 10.2 MiB Load Address: Entry Point: Verifying Checksum ... OK X5000> load sata 0:1 200 cyrus.dtb reading cyrus.dtb 29244 bytes read in 27 m
Re: use generic DMA mapping code in powerpc V4
Hello Christoph, I was able to compile 257002094bc5935dd63207a380d9698ab81f0775 from your Git powerpc-dma.6-debug today. Unfortunately I don't see any error messages (kernel ring buffer) and I don't have a RS232 serial null modem cable to get them. Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Sorry, it's not possible to patch
'257002094bc5935dd63207a380d9698ab81f0775' with your patch. I also tried
it manually but without any success.
-- Christian
On 18 January 2019 at 1:18PM, Christoph Hellwig wrote:
On Fri, Jan 18, 2019 at 01:07:54PM +0100, Christian Zigotzky wrote:
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 257002094bc5935dd63207a380d9698ab81f0775
I get the following error message with your patch:
Hmm. Did I attached the wrong patch? Here is the one I want and just
applied to that revision:
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev,
size_t size,
page = NULL;
}
}
- if (!page)
+ if (!page) {
page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
+ if (!page)
+ pr_warn("failed to allocate memory with gfp 0x%x\n",
gfp);
+ }
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
__free_pages(page, page_order);
@@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev,
size_t size,
}
}
+ if (!page) {
+ pr_warn("failed to allocate DMA memory!\n");
+ dump_stack();
+ }
return page;
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 257002094bc5935dd63207a380d9698ab81f0775 I get the following error message with your patch: patching file a/kernel/dma/direct.c Hunk #1 FAILED at 118. Hunk #2 FAILED at 139. 2 out of 2 hunks FAILED -- saving rejects to file a/kernel/dma/direct.c.rej -- Christian On 18 January 2019 at 12:28PM, Christoph Hellwig wrote: On Fri, Jan 18, 2019 at 12:10:26PM +0100, Christian Zigotzky wrote: For which commit? On top of 257002094bc5935dd63207a380d9698ab81f0775, that is the first one you identified as breaking the detection of the SATA disks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
For which commit?
-- Christian
On 18 January 2019 at 09:35AM, Christoph Hellwig wrote:
Hi Christian,
can you check if the debug printks in this patch trigger?
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..e46c9b64ec0d 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -118,8 +118,11 @@ struct page *__dma_direct_alloc_pages(struct device *dev,
size_t size,
page = NULL;
}
}
- if (!page)
+ if (!page) {
page = alloc_pages_node(dev_to_node(dev), gfp, page_order);
+ if (!page)
+ pr_warn("failed to allocate memory with gfp 0x%x\n",
gfp);
+ }
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
__free_pages(page, page_order);
@@ -139,6 +142,10 @@ struct page *__dma_direct_alloc_pages(struct device *dev,
size_t size,
}
}
+ if (!page) {
+ pr_warn("failed to allocate DMA memory!\n");
+ dump_stack();
+ }
return page;
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi All, I compiled the fixed '257002094bc5935dd63207a380d9698ab81f0775' (powerpc/dma: use the dma-direct allocator for coherent platforms) today. git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 257002094bc5935dd63207a380d9698ab81f0775 Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage The X1000 boots and the PASEMI onboard ethernet works! Bad news for the X5000 (P5020 board). U-Boot loads the kernel and the dtb file. Then the kernel starts but it doesn't find any hard disks (partitions). Cheers, Christian On 15 January 2019 at 4:17PM, Christoph Hellwig wrote: So 257002094bc5935dd63207a380d9698ab81f0775 above is the fixed version for the commit - this switched the ifdef in dma.c around that I had inverted. Can you try that one instead? And then move on with the commits after it in the updated powerpc-dma.6 branch - they are identical to the original branch except for carrying this fix forward. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 15 January 2019 at 2:35PM, Christoph Hellwig wrote:
On Tue, Jan 15, 2019 at 11:55:25AM +0100, Christian Zigotzky wrote:
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the
generic direct mapping bypass)
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 21074ef03c0816ae158721a78cabe9035938
I was able to compile the kernel for the AmigaOne X1000 (Nemo board with PA
Semi PA6T-1682M SoC). It boots but the PA Semi onboard ethernet doesn't
work.
Thanks. But we are exactly missing the steps that are relevant. I've
pushed a fixed up powerpc-dma.6 tree, which will only change starting from
the first commit that didn't link.
The first commit that changed from the old one is this one:
http://git.infradead.org/users/hch/misc.git/commitdiff/257002094bc5935dd63207a380d9698ab81f0775
which was that one that your compile failed on first.
Thanks again for all your work!
Thank you! I tried the commit 240d7ecd7f6fa62e074e8a835e620047954f0b28
(powerpc/dma: use the dma-direct allocator for coherent platforms) again.
git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a
git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28
I modified the 'dma.c' patch because of the undefined references to
'__dma_nommu_free_coherent' and '__dma_nommu_alloc_coherent':
---
@@ -163,8 +99,13 @@ static inline void dma_nommu_sync_single(struct
device *dev,
#endif
const struct dma_map_ops dma_nommu_ops = {
+ .alloc = dma_direct_alloc,
+ .free = dma_direct_free,
.map_sg = dma_nommu_map_sg,
.unmap_sg = dma_nommu_unmap_sg,
.dma_supported = dma_direct_supported,
---
The X1000 boots and the PASEMI onboard ethernet works! X5000 (P5020
board): U-Boot loads the kernel and the dtb file. Then the kernel starts
but it doesn't find any hard disks (partitions).
-- Christian
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 21074ef03c0816ae158721a78cabe9035938 (powerpc/dma: use the generic direct mapping bypass) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 21074ef03c0816ae158721a78cabe9035938 I was able to compile the kernel for the AmigaOne X1000 (Nemo board with PA Semi PA6T-1682M SoC). It boots but the PA Semi onboard ethernet doesn't work. dmesg: [ 12.698063] pasemi_mac :00:14.3 enp0s20f3: renamed from eth0 [ 16.516966] IPv6: ADDRCONF(NETDEV_UP): enp0s20f3: link is not ready [ 16.521025] pci :00:1a.0: overflow 0x00026a587802+1646 of DMA mask bus mask 0 [ 16.521047] WARNING: CPU: 0 PID: 2318 at kernel/dma/direct.c:43 .dma_direct_map_page+0x11c/0x200 [ 16.521049] Modules linked in: [ 16.521056] CPU: 0 PID: 2318 Comm: NetworkManager Not tainted 5.0.0-rc2-2_A-EON_AmigaOne_X1000_Nemo-54576-g21074ef-dirty #1 [ 16.521059] NIP: c010395c LR: c0103a30 CTR: [ 16.521062] REGS: c0026a1a29a0 TRAP: 0700 Not tainted (5.0.0-rc2-2_A-EON_AmigaOne_X1000_Nemo-54576-g21074ef-dirty) [ 16.521064] MSR: 9202b032 CR: 22002442 XER: 2000 [ 16.521074] IRQMASK: 0 GPR00: c0103a30 c0026a1a2c30 c1923f00 0052 GPR04: c0026f206778 c0026f20d458 c1ab1178 7063693a30303030 GPR08: 0007 0010 GPR12: 3a30303a31612e30 c1b1 00a79020 00ace140 GPR16: fffdd958 c0026be92220 GPR20: c0026a47 GPR24: 0800 c0026a1c c0026bc69280 c0026a1c GPR28: c00277b1f588 066e c0026d3c68b0 0802 [ 16.52] NIP [c010395c] .dma_direct_map_page+0x11c/0x200 [ 16.521114] LR [c0103a30] .dma_direct_map_page+0x1f0/0x200 [ 16.521116] Call Trace: [ 16.521120] [c0026a1a2c30] [c0103a30] .dma_direct_map_page+0x1f0/0x200 (unreliable) [ 16.521126] [c0026a1a2cd0] [c099b84c] .pasemi_mac_replenish_rx_ring+0x12c/0x2a0 [ 16.521131] [c0026a1a2da0] [c099dcc4] .pasemi_mac_open+0x384/0x7c0 [ 16.521137] [c0026a1a2e40] [c0c6f4e4] .__dev_open+0x134/0x1e0 [ 16.521142] [c0026a1a2ee0] [c0c6fa4c] .__dev_change_flags+0x1bc/0x210 [ 16.521147] [c0026a1a2f90] [c0c6fae8] .dev_change_flags+0x48/0xa0 [ 16.521153] [c0026a1a3030] [c0c8c8ec] .do_setlink+0x3dc/0xf60 [ 16.521158] [c0026a1a31b0] [c0c8dde4] .__rtnl_newlink+0x5e4/0x900 [ 16.521163] [c0026a1a35f0] [c0c8e16c] .rtnl_newlink+0x6c/0xb0 [ 16.521167] [c0026a1a3680] [c0c89898] .rtnetlink_rcv_msg+0x2e8/0x3d0 [ 16.521172] [c0026a1a3760] [c0cc0ff0] .netlink_rcv_skb+0x120/0x170 [ 16.521177] [c0026a1a3820] [c0c87378] .rtnetlink_rcv+0x28/0x40 [ 16.521181] [c0026a1a38a0] [c0cc0458] .netlink_unicast+0x208/0x2f0 [ 16.521186] [c0026a1a3950] [c0cc0a08] .netlink_sendmsg+0x348/0x460 [ 16.521190] [c0026a1a3a30] [c0c387d4] .sock_sendmsg+0x44/0x70 [ 16.521195] [c0026a1a3ab0] [c0c3a7fc] .___sys_sendmsg+0x30c/0x320 [ 16.521199] [c0026a1a3ca0] [c0c3c414] .__sys_sendmsg+0x74/0xf0 [ 16.521204] [c0026a1a3d90] [c0cb4e00] .__se_compat_sys_sendmsg+0x40/0x60 [ 16.521210] [c0026a1a3e20] [c000a21c] system_call+0x5c/0x70 [ 16.521212] Instruction dump: [ 16.521215] 6000 f8610070 3d20 6129fffe 79290020 e8e7 7fa74840 409d00b8 [ 16.521222] 3d420001 892acb59 2f89 419e00b8 <0fe0> 382100a0 3860 e8010010 [ 16.521231] ---[ end trace 2129e4121bbdd0e9 ]--- I wasn't able to compile it for the AmigaOne X5000 (Cyrus+ board with Qoriq P5020 SoC). Error message: CALL scripts/checksyscalls.sh CHK include/generated/compile.h CC arch/powerpc/sysdev/fsl_pci.o arch/powerpc/sysdev/fsl_pci.c: In function 'fsl_pci_dma_set_mask': arch/powerpc/sysdev/fsl_pci.c:142:21: error: 'dma_nommu_ops' undeclared (first use in this function) set_dma_ops(dev, _nommu_ops); ^ arch/powerpc/sysdev/fsl_pci.c:142:21: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:276: recipe for target 'arch/powerpc/sysdev/fsl_pci.o' failed make[2]: *** [arch/powerpc/sysdev/fsl_pci.o] Error 1 scripts/Makefile.build:492: recipe for target 'arch/powerpc/sysdev' failed make[1]: *** [arch/powerpc/sysdev] Error 2 Makefile:1049: recipe for target 'arch/powerpc' failed make: *** [arch/powerpc] Error 2 -- Christian On 15 January 2019 at 09:49AM, Christian Zigotzky wrote: Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (p
Re: use generic DMA mapping code in powerpc V4
Next step: 63a6e350e037a21e9a88c8b710129bea7049a80f (powerpc/dma: use the dma_direct mapping routines) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 63a6e350e037a21e9a88c8b710129bea7049a80f Error message: arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to `__dma_nommu_alloc_coherent' arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to `__dma_nommu_free_coherent' Makefile:1027: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 -- Christian On 15 January 2019 at 09:07AM, Christian Zigotzky wrote: Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use the dma-direct allocator for coherent platforms) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28 Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage Error message: arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to `__dma_nommu_alloc_coherent' arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to `__dma_nommu_free_coherent' Makefile:1027: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 -- Christian On 12 January 2019 at 7:14PM, Christian Zigotzky wrote: Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove swiotlb_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 Output: You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 11 January 2019 at 03:10AM, Christian Zigotzky wrote: Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove dma_nommu_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02 Output: Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported --- Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 09 January 2019 at 10:31AM, Christian Zigotzky wrote: Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove dma_nommu_get_required_mask) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout a64e18ba191ba9102fb174f27d707485ffd9389c Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 05 January 2019 at 5:03PM, Christian Zigotzky wrote: Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout
Re: use generic DMA mapping code in powerpc V4
Next step: 240d7ecd7f6fa62e074e8a835e620047954f0b28 (powerpc/dma: use the dma-direct allocator for coherent platforms) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 240d7ecd7f6fa62e074e8a835e620047954f0b28 Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc zImage Error message: arch/powerpc/kernel/dma.o:(.data.rel.ro+0x0): undefined reference to `__dma_nommu_alloc_coherent' arch/powerpc/kernel/dma.o:(.data.rel.ro+0x8): undefined reference to `__dma_nommu_free_coherent' Makefile:1027: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 -- Christian On 12 January 2019 at 7:14PM, Christian Zigotzky wrote: Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove swiotlb_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 Output: You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 11 January 2019 at 03:10AM, Christian Zigotzky wrote: Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove dma_nommu_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02 Output: Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported --- Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 09 January 2019 at 10:31AM, Christian Zigotzky wrote: Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove dma_nommu_get_required_mask) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout a64e18ba191ba9102fb174f27d707485ffd9389c Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 05 January 2019 at 5:03PM, Christian Zigotzky wrote: Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent - Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 (swiotlb: remove swiotlb_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 4558b6e1ddf3dcf5a86d6a5d16c2ac1600c7df39 Output: You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 4558b6e... swiotlb: remove swiotlb_dma_supported Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet (X1000) works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 11 January 2019 at 03:10AM, Christian Zigotzky wrote: Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove dma_nommu_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02 Output: Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported --- Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 09 January 2019 at 10:31AM, Christian Zigotzky wrote: Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove dma_nommu_get_required_mask) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout a64e18ba191ba9102fb174f27d707485ffd9389c Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 05 January 2019 at 5:03PM, Christian Zigotzky wrote: Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent - Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 891dcc1072f1fa27a83da920d88daff6ca08fc02 (powerpc/dma: remove dma_nommu_dma_supported) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout 891dcc1072f1fa27a83da920d88daff6ca08fc02 Output: Note: checking out '891dcc1072f1fa27a83da920d88daff6ca08fc02'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 891dcc1... powerpc/dma: remove dma_nommu_dma_supported --- Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 09 January 2019 at 10:31AM, Christian Zigotzky wrote: Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove dma_nommu_get_required_mask) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout a64e18ba191ba9102fb174f27d707485ffd9389c Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 05 January 2019 at 5:03PM, Christian Zigotzky wrote: Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent - Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: a64e18ba191ba9102fb174f27d707485ffd9389c (powerpc/dma: remove dma_nommu_get_required_mask) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout a64e18ba191ba9102fb174f27d707485ffd9389c Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Results: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. I also successfully tested sound, hardware 3D acceleration, Bluetooth, network, booting with a label etc. The uImages work also in a virtual e5500 quad-core QEMU machine. -- Christian On 05 January 2019 at 5:03PM, Christian Zigotzky wrote: Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent - Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: c446404b041130fbd9d1772d184f24715cf2362f (powerpc/dma: remove dma_nommu_mmap_coherent) git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.6 a git checkout c446404b041130fbd9d1772d184f24715cf2362f Output: Note: checking out 'c446404b041130fbd9d1772d184f24715cf2362f'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at c446404... powerpc/dma: remove dma_nommu_mmap_coherent - Link to the Git: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, Happy new year for you too. Unfortunately we have some problems with the latest DRM patches. They modified a lot and some graphics cards don’t work anymore. During the holidays we tried to figure out where the problems are but without any success. I will try to test your patches next week. Cheers, Christian Sent from my iPhone > On 3. Jan 2019, at 08:36, Christoph Hellwig wrote: > > Hi Christian, > > happy new year and I hope you had a few restful deays off. > > I've pushed a new tree to: > > git://git.infradead.org/users/hch/misc.git powerpc-dma.6 > > Gitweb: > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6 > > Which has been rebased to the latests Linus tree, which has a lot of > changes, and has also changed the patch split a bit to aid bisection. > > I think > > > http://git.infradead.org/users/hch/misc.git/commitdiff/c446404b041130fbd9d1772d184f24715cf2362f > > might be a good commit to re-start testing, then bisecting up to the > last commit using git bisect. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 12 December 2018 at 3:15PM, Christoph Hellwig wrote: > Thanks for bisecting. I've spent some time going over the conversion > but can't really pinpoint it. I have three little patches that switch > parts of the code to the generic version. This is on top of the > last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda). > > Can you check with whіch one things stop working? Hello Christoph, Great news! All your patches work! I tested all your patches (including the patch '0004-alloc-free.patch' today) and the PASEMI onboard ethernet works and the P5020 board boots without any problems. Thank you for your work! I have a few days off. That means, I will work less and only for the A-EON first level Linux support. I can test again on Thursday next week. Have a nice weekend! Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 13 December 2018 at 6:48PM, Christian Zigotzky wrote: On 13 December 2018 at 2:34PM, Christian Zigotzky wrote: On 13 December 2018 at 12:25PM, Christoph Hellwig wrote: On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: I tried it again but I get the following error message: MODPOST vmlinux.o arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask': (.text+0x274): undefined reference to `.dma_direct_get_required_mask' make: *** [vmlinux] Error 1 Sorry, you need this one liner before all the patches posted last time: diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d8819e3a1eb1..7e78c2798f2f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -154,6 +154,7 @@ config PPC select CLONE_BACKWARDS select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN select DYNAMIC_FTRACE if FUNCTION_TRACER + select DMA_DIRECT_OPS select EDAC_ATOMIC_SCRUB select EDAC_SUPPORT select GENERIC_ATOMIC64 if PPC32 Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots with the patch '0001-get_required_mask.patch'. -- Christian Next patch: '0002-swiotlb-dma_supported.patch' for the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). The PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian Next patch: '0003-nommu-dma_supported.patch' No problems with the PASEMI onboard ethernet and the P5020 board boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 13 December 2018 at 2:34PM, Christian Zigotzky wrote: On 13 December 2018 at 12:25PM, Christoph Hellwig wrote: On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: I tried it again but I get the following error message: MODPOST vmlinux.o arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask': (.text+0x274): undefined reference to `.dma_direct_get_required_mask' make: *** [vmlinux] Error 1 Sorry, you need this one liner before all the patches posted last time: diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d8819e3a1eb1..7e78c2798f2f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -154,6 +154,7 @@ config PPC select CLONE_BACKWARDS select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN select DYNAMIC_FTRACE if FUNCTION_TRACER + select DMA_DIRECT_OPS select EDAC_ATOMIC_SCRUB select EDAC_SUPPORT select GENERIC_ATOMIC64 if PPC32 Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots with the patch '0001-get_required_mask.patch'. -- Christian Next patch: '0002-swiotlb-dma_supported.patch' for the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). The PASEMI onboard ethernet works and the X5000 (P5020 board) boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 13 December 2018 at 12:25PM, Christoph Hellwig wrote: On Thu, Dec 13, 2018 at 12:19:26PM +0100, Christian Zigotzky wrote: I tried it again but I get the following error message: MODPOST vmlinux.o arch/powerpc/kernel/dma-iommu.o: In function `.dma_iommu_get_required_mask': (.text+0x274): undefined reference to `.dma_direct_get_required_mask' make: *** [vmlinux] Error 1 Sorry, you need this one liner before all the patches posted last time: diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d8819e3a1eb1..7e78c2798f2f 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -154,6 +154,7 @@ config PPC select CLONE_BACKWARDS select DCACHE_WORD_ACCESS if PPC64 && CPU_LITTLE_ENDIAN select DYNAMIC_FTRACE if FUNCTION_TRACER + select DMA_DIRECT_OPS select EDAC_ATOMIC_SCRUB select EDAC_SUPPORT select GENERIC_ATOMIC64 if PPC32 Thanks. Result: PASEMI onboard ethernet works and the X5000 (P5020 board) boots with the patch '0001-get_required_mask.patch'. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 13 December 2018 at 10:10AM, Christoph Hellwig wrote: On Thu, Dec 13, 2018 at 09:41:50AM +0100, Christian Zigotzky wrote: Today I tried the first patch (0001-get_required_mask.patch) with the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this patch is already included in the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). I will try the next patch. Hmm, I don't think this is the case. This is my local git log output: commit 83a4b87de6bc6a75b500c9959de88e2157fbcd7c Author: Christoph Hellwig Date: Wed Dec 12 15:07:49 2018 +0100 get_required_mask commit 977706f9755d2d697aa6f45b4f9f0e07516efeda Author: Christoph Hellwig Date: Sat Nov 10 22:34:27 2018 +0100 powerpc/dma: remove dma_nommu_mmap_coherent I've also pushed a git branch with these out to: git://git.infradead.org/users/hch/misc.git powerpc-dma.5-debug Sorry Christioph. I was wrong. The first patch isn't included in the last good commit. I will try it again. I can only test beside my main work. That means it takes longer. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 12 December 2018 at 3:39PM, Christian Zigotzky wrote: Hi Christoph, Thanks a lot for your reply. I will test your patches tomorrow. Cheers, Christian Sent from my iPhone On 12. Dec 2018, at 15:15, Christoph Hellwig wrote: Thanks for bisecting. I've spent some time going over the conversion but can't really pinpoint it. I have three little patches that switch parts of the code to the generic version. This is on top of the last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Can you check with whіch one things stop working? <0001-get_required_mask.patch> <0002-swiotlb-dma_supported.patch> <0003-nommu-dma_supported.patch> <0004-alloc-free.patch> Today I tried the first patch (0001-get_required_mask.patch) with the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). Unfortunately this patch is already included in the last good commit (977706f9755d2d697aa6f45b4f9f0e07516efeda). I will try the next patch. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph, Thanks a lot for your reply. I will test your patches tomorrow. Cheers, Christian Sent from my iPhone > On 12. Dec 2018, at 15:15, Christoph Hellwig wrote: > > Thanks for bisecting. I've spent some time going over the conversion > but can't really pinpoint it. I have three little patches that switch > parts of the code to the generic version. This is on top of the > last good commmit (977706f9755d2d697aa6f45b4f9f0e07516efeda). > > Can you check with whіch one things stop working? > > > <0001-get_required_mask.patch> > <0002-swiotlb-dma_supported.patch> > <0003-nommu-dma_supported.patch> > <0004-alloc-free.patch> ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
> On 12. Dec 2018, at 01:47, Benjamin Herrenschmidt > wrote: > >> On Tue, 2018-12-11 at 19:17 +0100, Christian Zigotzky wrote: >> X5000 (P5020 board): U-Boot loads the kernel and the dtb file. Then the >> kernel starts but it doesn't find any hard disks (partitions). That >> means this is also the bad commit for the P5020 board. > > What are the disks hanging off ? A PCIe device of some sort ? > > Can you send good & bad dmesg logs ? > > Ben. > > Unfortunately not. It doesn’t detect any hard disk. That means the kernel ring buffer won’t save to log files. I don’t have a serial null modem cable for seeing all output. We use SATA disks. I will investigate more in this problem with rollback the files in the bad commit. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 977706f9755d2d697aa6f45b4f9f0e07516efeda (powerpc/dma: remove dma_nommu_mmap_coherent) Result: The P5020 board boots and the PASEMI onboard ethernet works. -- Christian On 10 December 2018 at 4:54PM, Christian Zigotzky wrote: Next step: 64ecd2c160bbef31465c4d34efc0f076a2aad4df (powerpc/dma: use phys_to_dma instead of get_dma_offset) The P5020 board boots and the PASEMI onboard ethernet works. -- Christian On 09 December 2018 at 7:26PM, Christian Zigotzky wrote: Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping, powerpc: simplify the arch dma_set_mask override) Result: No problems with the PASEMI onboard ethernet and with booting the X5000 (P5020 board). -- Christian On 09 December 2018 at 3:20PM, Christian Zigotzky wrote: Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci: simplify fsl_pci_dma_set_mask) git checkout 602307b034734ce77a05da4b99333a2eaf6b6482 The PASEMI onboard ethernet works and the X5000 boots. -- Christian On 08 December 2018 at 2:47PM, Christian Zigotzky wrote: Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an off-by-one in dma_capable) git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 The PASEMI onboard ethernet also works with this commit and the X5000 boots without any problems. -- Christian On 08 December 2018 at 11:29AM, Christian Zigotzky wrote: Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove max_direct_dma_addr) git checkout 7ebc44c535f6bd726d553756d38b137acc718443 OK, the PASEMI onboard ethernet works and the P5020 board boots. -- Christian On 07 December 2018 at 7:33PM, Christian Zigotzky wrote: Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the P5020 board boots. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 64ecd2c160bbef31465c4d34efc0f076a2aad4df (powerpc/dma: use phys_to_dma instead of get_dma_offset) The P5020 board boots and the PASEMI onboard ethernet works. -- Christian On 09 December 2018 at 7:26PM, Christian Zigotzky wrote: Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping, powerpc: simplify the arch dma_set_mask override) Result: No problems with the PASEMI onboard ethernet and with booting the X5000 (P5020 board). -- Christian On 09 December 2018 at 3:20PM, Christian Zigotzky wrote: Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci: simplify fsl_pci_dma_set_mask) git checkout 602307b034734ce77a05da4b99333a2eaf6b6482 The PASEMI onboard ethernet works and the X5000 boots. -- Christian On 08 December 2018 at 2:47PM, Christian Zigotzky wrote: Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an off-by-one in dma_capable) git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 The PASEMI onboard ethernet also works with this commit and the X5000 boots without any problems. -- Christian On 08 December 2018 at 11:29AM, Christian Zigotzky wrote: Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove max_direct_dma_addr) git checkout 7ebc44c535f6bd726d553756d38b137acc718443 OK, the PASEMI onboard ethernet works and the P5020 board boots. -- Christian On 07 December 2018 at 7:33PM, Christian Zigotzky wrote: Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the P5020 board boots. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a (dma-mapping, powerpc: simplify the arch dma_set_mask override) Result: No problems with the PASEMI onboard ethernet and with booting the X5000 (P5020 board). -- Christian On 09 December 2018 at 3:20PM, Christian Zigotzky wrote: Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci: simplify fsl_pci_dma_set_mask) git checkout 602307b034734ce77a05da4b99333a2eaf6b6482 The PASEMI onboard ethernet works and the X5000 boots. -- Christian On 08 December 2018 at 2:47PM, Christian Zigotzky wrote: Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an off-by-one in dma_capable) git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 The PASEMI onboard ethernet also works with this commit and the X5000 boots without any problems. -- Christian On 08 December 2018 at 11:29AM, Christian Zigotzky wrote: Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove max_direct_dma_addr) git checkout 7ebc44c535f6bd726d553756d38b137acc718443 OK, the PASEMI onboard ethernet works and the P5020 board boots. -- Christian On 07 December 2018 at 7:33PM, Christian Zigotzky wrote: Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the P5020 board boots. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 602307b034734ce77a05da4b99333a2eaf6b6482 (powerpc/fsl_pci: simplify fsl_pci_dma_set_mask) git checkout 602307b034734ce77a05da4b99333a2eaf6b6482 The PASEMI onboard ethernet works and the X5000 boots. -- Christian On 08 December 2018 at 2:47PM, Christian Zigotzky wrote: Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an off-by-one in dma_capable) git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 The PASEMI onboard ethernet also works with this commit and the X5000 boots without any problems. -- Christian On 08 December 2018 at 11:29AM, Christian Zigotzky wrote: Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove max_direct_dma_addr) git checkout 7ebc44c535f6bd726d553756d38b137acc718443 OK, the PASEMI onboard ethernet works and the P5020 board boots. -- Christian On 07 December 2018 at 7:33PM, Christian Zigotzky wrote: Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the P5020 board boots. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 (powerpc/dma: fix an off-by-one in dma_capable) git checkout e15cd8173ef85e9cc3e2a9c7cc2982f5c1355615 The PASEMI onboard ethernet also works with this commit and the X5000 boots without any problems. -- Christian On 08 December 2018 at 11:29AM, Christian Zigotzky wrote: Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove max_direct_dma_addr) git checkout 7ebc44c535f6bd726d553756d38b137acc718443 OK, the PASEMI onboard ethernet works and the P5020 board boots. -- Christian On 07 December 2018 at 7:33PM, Christian Zigotzky wrote: Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the P5020 board boots. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Next step: 7ebc44c535f6bd726d553756d38b137acc718443 (powerpc/dma: remove max_direct_dma_addr) git checkout 7ebc44c535f6bd726d553756d38b137acc718443 OK, the PASEMI onboard ethernet works and the P5020 board boots. -- Christian On 07 December 2018 at 7:33PM, Christian Zigotzky wrote: Next step: 13c1fdec5682b6e13257277fa16aa31f342d167d (powerpc/dma: move pci_dma_dev_setup_swiotlb to fsl_pci.c) git checkout 13c1fdec5682b6e13257277fa16aa31f342d167d Result: The PASEMI onboard ethernet works and the P5020 board boots. — Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/34] powerpc: use mm zones more sensibly
I will work at the weekend to figure out where the problematic commit is. — Christian Sent from my iPhone > On 7. Dec 2018, at 15:09, Christoph Hellwig wrote: > >> On Fri, Dec 07, 2018 at 11:18:18PM +1100, Michael Ellerman wrote: >> Christoph Hellwig writes: >> >>> Ben / Michael, >>> >>> can we get this one queued up for 4.21 to prepare for the DMA work later >>> on? >> >> I was hoping the PASEMI / NXP regressions could be solved before >> merging. >> >> My p5020ds is booting fine with this series, so I'm not sure why it's >> causing problems on Christian's machine. >> >> The last time I turned on my PASEMI board it tripped some breakers, so I >> need to investigate that before I can help test that. >> >> I'll see how things look on Monday and either merge the commits you >> identified or the whole series depending on if there's any more info >> from Christian. > > Christian just confirmed everything up to at least > "powerpc/dma: stop overriding dma_get_required_mask" works for his > setups. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 06 December 2018 at 11:55AM, Christian Zigotzky wrote: On 05 December 2018 at 3:05PM, Christoph Hellwig wrote: Thanks. Can you try a few stepping points in the tree? First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 (the first one) applied? Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b And if that still works with commits up to c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a Hi Christoph, I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the following command: git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 Result: PASEMI onboard ethernet works again and the P5020 board boots. I will test the other commits in the next days. @All It is really important, that you also test Christoph's work on your PASEMI and NXP boards. Could you please help us with solving the issues? 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian Today I tested the commit 5da11e49df21f21dac25a2491aa788307bdacb6b. git checkout 5da11e49df21f21dac25a2491aa788307bdacb6b The PASEMI onboard ethernet works and the P5020 board boots. -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Good to know. Sorry because of the email. Sent from my iPhone > On 6. Dec 2018, at 20:36, Christoph Hellwig wrote: > >> On Thu, Dec 06, 2018 at 06:10:54PM +0100, Christian Zigotzky wrote: >> Please don’t merge this code. We are still testing and trying to figure out >> where the problems are in the code. > > The ones I sent pings for were either tested successfully by you > (the zone change) or are trivial cleanups that don't affect your setup. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Please don’t merge this code. We are still testing and trying to figure out where the problems are in the code. — Christian Sent from my iPhone > On 6. Dec 2018, at 11:55, Christian Zigotzky wrote: > >> On 05 December 2018 at 3:05PM, Christoph Hellwig wrote: >> >> Thanks. Can you try a few stepping points in the tree? >> >> First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 >> (the first one) applied? >> >> Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b >> >> And if that still works with commits up to >> c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a >> > Hi Christoph, > > I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the > following command: > > git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 > > Result: PASEMI onboard ethernet works again and the P5020 board boots. > > I will test the other commits in the next days. > > @All > It is really important, that you also test Christoph's work on your PASEMI > and NXP boards. Could you please help us with solving the issues? > > 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' > > Thanks, > Christian > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 05 December 2018 at 3:05PM, Christoph Hellwig wrote: Thanks. Can you try a few stepping points in the tree? First just with commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 (the first one) applied? Second with all commits up to 5da11e49df21f21dac25a2491aa788307bdacb6b And if that still works with commits up to c1bfcad4b0cf38ce5b00f7ad880d3a13484c123a Hi Christoph, I undid the commit 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 with the following command: git checkout 7fd3bb05b73beea1f9840b505aa09beb9c75a8c6 Result: PASEMI onboard ethernet works again and the P5020 board boots. I will test the other commits in the next days. @All It is really important, that you also test Christoph's work on your PASEMI and NXP boards. Could you please help us with solving the issues? 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 04 December 2018 at 3:24PM, Christoph Hellwig wrote: On Tue, Dec 04, 2018 at 10:53:39AM +0100, Christian Zigotzky wrote: I don't know why this kernel doesn't recognize the hard disks connected to my physical P5020 board and why the onboard ethernet on my PASEMI board doesn't work. (dma_direct_map_page: overflow) Do you know if this actually works for the baseline before my patches? E.g. with commit 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97 ? Hi Christoph, Thanks for your reply. I undid all dma mapping commits with the following command: git checkout 721c01ba8b46ddb5355bd6e6b3bbfdabfdf01e97 After that I compiled the kernels with this code for my P5020 board (Cyrus) and for my PASEMI board (Nemo) today. Result: PASEMI onboard ethernet works again and the P5020 board boots. It seems the dma mapping commits are the problem. @All Could you please test Christoph's kernel on your PASEMI and NXP boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 04 December 2018 at 08:31AM, Christian Zigotzky wrote: Hi All, Could you please test Christoph's kernel on your PASEMI and NXP boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian I successfully tested this kernel on a virtual e5500 QEMU machine today. Command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel uImage-dma -drive format=raw,file=MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio -nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw es1370 -smp 4 QEMU version 3.1.0. I don't know why this kernel doesn't recognize the hard disks connected to my physical P5020 board and why the onboard ethernet on my PASEMI board doesn't work. (dma_direct_map_page: overflow) -- Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi All, Could you please test Christoph's kernel on your PASEMI and NXP boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hello Christoph, Thanks for your reply. On 30 November 2018 at 2:10PM, Christoph Hellwig wrote: On Fri, Nov 30, 2018 at 01:23:20PM +0100, Christian Zigotzky wrote: Yes, of course. I patched your Git kernel and after that I compiled it again. U-Boot loads the kernel and the dtb file. Then the kernel starts but it doesn't find any hard disks (partitions). Interesting. Does it find the storage controller (what kind of storage does it use?). It seems not. I don't see any infos about hard disks in the kernel ring buffer. The two serial ATA (SATA 2.0) controllers are integrated in the P5020 SoC and the hard disks are connected via SerDes lanes (PCIe) to the SoC. LANE 16 = SATA 0 and LANE 17 = SATA 1. For the PASEMI board can you test the attached patch? Also are you using Compact Flash cards on that system? Yes, we are using Compact Flash cards. The slot is wired to the CPU local bus. It works with your kernel. :-) Where is the attached patch? I downloaded the version 5 of your Git kernel and compiled it today. Unfortunately the PASEMI ethernet doesn't work. Error message: pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 @All Could you please also test Christoph's kernel on your PASEMI and NXP boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.5 a' Thanks, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
Hi Christoph,
Thanks a lot for your fast reply.
On 30 November 2018 at 11:53AM, Christoph Hellwig wrote:
Hi Christian,
for such a diverse architecture like powerpc we'll have to rely on
users / non core developers like you to help with testing.
I see. I will help as good as I can.
Can you try the patch below for he cyrus config?
Yes, of course. I patched your Git kernel and after that I compiled it
again. U-Boot loads the kernel and the dtb file. Then the kernel starts
but it doesn't find any hard disks (partitions).
@All
Could you please also test Christoph's kernel on your PASEMI and NXP
boards? Download: 'git clone git://git.infradead.org/users/hch/misc.git
-b powerpc-dma.4 a'
*PLEASE*
For the nemo one I have no idea yet,
We had some problems with the PASEMI ethernet and DMA two years ago. I
had to deactivate the option PASEMI_IOMMU_DMA_FORCE.
commit 416f37d0816b powerpc/pasemi: Fix coherent_dma_mask for dma engine:
Commit 817820b0 ("powerpc/iommu: Support "hybrid" iommu/direct DMA
ops for coherent_mask < dma_mask) adds a check of coherent_dma_mask for
dma allocations.
Unfortunately current PASemi code does not set this value for the DMA
engine, which ends up with the default value of 0x, the result
is on a PASemi system with >2Gb ram and iommu enabled the onboard
ethernet stops working due to an inability to allocate memory. Add an
initialisation to pci_dma_dev_setup_pasemi().
Signed-off-by: Darren Stevens
Signed-off-by: Michael Ellerman
Links:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-July/146701.html
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=416f37d0816b9720b8227953e55954d81456f991
FYI: DMA handling has been rewritten in 2015. We had some problems with
the new DMA code in 2015. I had to revert the commit ' [RFC/PATCH,v2]
powerpc/iommu: Support "hybrid" iommu/direct DMA ops for coherent_mask <
dma_mask' in 2015.
Link: https://patchwork.ozlabs.org/patch/472535/
I had to create a patch in 2015:
diff -rupN linux-4.4/arch/powerpc/Kconfig
linux-4.4-nemo/arch/powerpc/Kconfig
--- linux-4.4/arch/powerpc/Kconfig 2015-12-07 00:43:12.0
+0100
+++ linux-4.4-nemo/arch/powerpc/Kconfig 2015-12-07
14:48:23.371987988 +0100
@@ -158,8 +155,6 @@ config PPC
select HAVE_PERF_EVENTS_NMI if PPC64
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
- select ARCH_HAS_DMA_SET_COHERENT_MASK
- select HAVE_ARCH_SECCOMP_FILTER
config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
@@ -419,8 +414,7 @@ config PPC64_SUPPORTS_MEMORY_FAILURE
config KEXEC
bool "kexec system call"
- depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP)) ||
PPC_BOOK3E
- select KEXEC_CORE
+ depends on (PPC_BOOK3S || FSL_BOOKE || (44x && !SMP))
help
kexec is a system call that implements the ability to
shutdown your
current kernel, and to start another kernel. It is like a
reboot
diff -rupN linux-4.4/arch/powerpc/kernel/dma.c
linux-4.4-nemo/arch/powerpc/kernel/dma.c
--- linux-4.4/arch/powerpc/kernel/dma.c 2015-12-07
00:43:12.0 +0100
+++ linux-4.4-nemo/arch/powerpc/kernel/dma.c 2015-12-07
14:49:38.098286892 +0100
@@ -40,31 +39,9 @@ static u64 __maybe_unused get_pfn_limit(
return pfn;
}
-static int dma_direct_dma_supported(struct device *dev, u64 mask)
-{
-#ifdef CONFIG_PPC64
- u64 limit = get_dma_offset(dev) + (memblock_end_of_DRAM() - 1);
-
- /* Limit fits in the mask, we are good */
- if (mask >= limit)
- return 1;
-
-#ifdef CONFIG_FSL_SOC
- /* Freescale gets another chance via ZONE_DMA/ZONE_DMA32, however
- * that will have to be refined if/when they support iommus
- */
- return 1;
-#endif
- /* Sorry ... */
- return 0;
-#else
- return 1;
-#endif
-}
-
-void *__dma_direct_alloc_coherent(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t flag,
- struct dma_attrs *attrs)
+void *dma_direct_alloc_coherent(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
{
void *ret;
#ifdef CONFIG_NOT_COHERENT_CACHE
@@ -119,9 +96,9 @@ void *__dma_direct_alloc_coherent(struct
#endif
}
-void __dma_direct_free_coherent(struct device *dev, size_t size,
- void *vaddr, dma_addr_t dma_handle,
- struct dma_attrs *attrs)
+void dma_direct_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
{
#ifdef CONFIG_NOT_COHERENT_CACHE
__dma_free_coherent(size, vaddr);
@@ -130,51 +107,6 @@ void __dma_direct_free_coherent(struct d
#endif
Re: use generic DMA mapping code in powerpc V4
On 29 November 2018 at 1:05PM, Christian Zigotzky wrote: On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Christoph Hellwig writes: Any comments? I'd like to at least get the ball moving on the easy bits. Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. There's not much we can do about that, but I'll just try and test it on everything I can find. Is the plan that you take these via the dma-mapping tree or that they go via powerpc? cheers Hi All, I compiled a test kernel from the following Git today. http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4 Command: git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.4 a Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't work anymore. [ 367.627623] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627631] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627639] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627647] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627655] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627686] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628418] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628505] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628592] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629324] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629417] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629495] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629589] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 430.424732]pasemi_mac: rcmdsta error: 0x04ef3001 I tested this kernel with the Nemo board (CPU: PWRficient PA6T-1682M). The PASEMI ethernet works with the RC4 of kernel 4.20. Cheers, Christian Hi All, I tested this kernel on my NXP QorIQ P5020 board. U-Boot loads the dtb file and the kernel and after that the booting stops. This board works with the RC4 of kernel 4.20. Please test this kernel on your NXP and PASEMI boards. Thanks, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Christoph Hellwig writes: Any comments? I'd like to at least get the ball moving on the easy bits. Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. There's not much we can do about that, but I'll just try and test it on everything I can find. Is the plan that you take these via the dma-mapping tree or that they go via powerpc? cheers Hi All, I compiled a test kernel from the following Git today. http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.4 Command: git clone git://git.infradead.org/users/hch/misc.git -b powerpc-dma.4 a Unfortunately I get some DMA error messages and the PASEMI ethernet doesn't work anymore. [ 367.627623] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627631] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627639] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627647] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627655] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.627686] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628418] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628505] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.628592] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629324] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629417] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629495] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 367.629589] pci :00:1a.0: dma_direct_map_page: overflow 0x00026bcb5002+110 of device mask bus mask 0 [ 430.424732]pasemi_mac: rcmdsta error: 0x04ef3001 I tested this kernel with the Nemo board (CPU: PWRficient PA6T-1682M). The PASEMI ethernet works with the RC4 of kernel 4.20. Cheers, Christian ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
I will compile and test the kernel from the following Git on my PowerPC machines. http://git.infradead.org/users/hch/misc.git On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: use generic DMA mapping code in powerpc V4
On 28 November 2018 at 12:05PM, Michael Ellerman wrote: Nothing specific yet. I'm a bit worried it might break one of the many old obscure platforms we have that aren't well tested. Please don't apply the new DMA mapping code if you don't be sure if it works on all supported PowerPC machines. Is the new DMA mapping code really necessary? It's not really nice, to rewrote code if the old code works perfect. We must not forget, that we work for the end users. Does the end user have advantages with this new code? Is it faster? The old code works without any problems. I am also worried about this code. How can I test this new DMA mapping code? Thanks ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
