* Re: [PATCH v2 00/21] Refine memblock API [not found] ` <CAHCN7xL1MkJh44N3W_1+08DHmX__SqnfH6dqUzYzr2Wpg0kQyQ@mail.gmail.com> @ 2019-10-03 5:34 ` Mike Rapoport 2019-10-03 8:49 ` Russell King - ARM Linux admin 0 siblings, 1 reply; 13+ messages in thread From: Mike Rapoport @ 2019-10-03 5:34 UTC (permalink / raw) To: Adam Ford Cc: Catalin Marinas, Russell King, The etnaviv authors, Linux Kernel Mailing List, Linux Memory Management List, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc, Lucas Stach (trimmed the CC) On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > Before the patch: > > # cat /sys/kernel/debug/memblock/memory > 0: 0x10000000..0x8fffffff > # cat /sys/kernel/debug/memblock/reserved > 0: 0x10004000..0x10007fff > 34: 0x2fffff88..0x3fffffff > > > After the patch: > # cat /sys/kernel/debug/memblock/memory > 0: 0x10000000..0x8fffffff > # cat /sys/kernel/debug/memblock/reserved > 0: 0x10004000..0x10007fff > 36: 0x80000000..0x8fffffff I'm still not convinced that the memblock refactoring didn't uncovered an issue in etnaviv driver. Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? BTW, the code that complained about "command buffer outside valid memory window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on MMUv2"). Could be that recent changes to MMU management of etnaviv resolve the issue? > > From 06529f861772b7dea2912fc2245debe4690139b8 Mon Sep 17 00:00:00 2001 > > From: Mike Rapoport <rppt@linux.ibm.com> > > Date: Wed, 2 Oct 2019 10:14:17 +0300 > > Subject: [PATCH] mm: memblock: do not enforce current limit for memblock_phys* > > family > > > > Until commit 92d12f9544b7 ("memblock: refactor internal allocation > > functions") the maximal address for memblock allocations was forced to > > memblock.current_limit only for the allocation functions returning virtual > > address. The changes introduced by that commit moved the limit enforcement > > into the allocation core and as a result the allocation functions returning > > physical address also started to limit allocations to > > memblock.current_limit. > > > > This caused breakage of etnaviv GPU driver: > > > > [ 3.682347] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) > > [ 3.688669] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) > > [ 3.695099] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) > > [ 3.700800] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108 > > [ 3.723013] etnaviv-gpu 130000.gpu: command buffer outside valid > > memory window > > [ 3.731308] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 > > [ 3.752437] etnaviv-gpu 134000.gpu: command buffer outside valid > > memory window > > [ 3.760583] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 > > [ 3.766766] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 > > > > Restore the behaviour of memblock_phys* family so that these functions will > > not enforce memblock.current_limit. > > > > This fixed the issue. Thank you > > Tested-by: Adam Ford <aford173@gmail.com> #imx6q-logicpd > > > Fixes: 92d12f9544b7 ("memblock: refactor internal allocation functions") > > Reported-by: Adam Ford <aford173@gmail.com> > > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> > > --- > > mm/memblock.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > index 7d4f61a..c4b16ca 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > align = SMP_CACHE_BYTES; > > } > > > > - if (end > memblock.current_limit) > > - end = memblock.current_limit; > > - > > again: > > found = memblock_find_in_range_node(size, align, start, end, nid, > > flags); > > @@ -1469,6 +1466,9 @@ static void * __init memblock_alloc_internal( > > if (WARN_ON_ONCE(slab_is_available())) > > return kzalloc_node(size, GFP_NOWAIT, nid); > > > > + if (max_addr > memblock.current_limit) > > + max_addr = memblock.current_limit; > > + > > alloc = memblock_alloc_range_nid(size, align, min_addr, max_addr, nid); > > > > /* retry allocation without lower limit */ > > -- > > 2.7.4 > > > > > > > > adam > > > > > > > > On Sat, Sep 28, 2019 at 2:33 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > On Thu, Sep 26, 2019 at 02:35:53PM -0500, Adam Ford wrote: > > > > > > On Thu, Sep 26, 2019 at 11:04 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > > > > > > > > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam <festevam@gmail.com> wrote: > > > > > > > > > > > > > > > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford <aford173@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > > > > > > > > change. Do we need to setup a reserved-memory node like > > > > > > > > > > imx6ul-ccimx6ulsom.dtsi did? > > > > > > > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > > > > > > > Were you able to identify what was the exact commit that caused such regression? > > > > > > > > > > > > > > > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > > > > > > > > internal allocation functions") that caused the regression with > > > > > > > > Etnaviv. > > > > > > > > > > > > > > > > > > > > > Can you please test with this change: > > > > > > > > > > > > > > > > > > > That appears to have fixed my issue. I am not sure what the impact > > > > > > is, but is this a safe option? > > > > > > > > > > It's not really a fix, I just wanted to see how exactly 92d12f9544b7 ("memblock: > > > > > refactor internal allocation functions") broke your setup. > > > > > > > > > > Can you share the dts you are using and the full kernel log? > > > > > > > > > > > adam > > > > > > > > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > > > > > index 7d4f61a..1f5a0eb 100644 > > > > > > > --- a/mm/memblock.c > > > > > > > +++ b/mm/memblock.c > > > > > > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > > > > > > align = SMP_CACHE_BYTES; > > > > > > > } > > > > > > > > > > > > > > - if (end > memblock.current_limit) > > > > > > > - end = memblock.current_limit; > > > > > > > - > > > > > > > again: > > > > > > > found = memblock_find_in_range_node(size, align, start, end, nid, > > > > > > > flags); > > > > > > > > > > > > > > > I also noticed that if I create a reserved memory node as was done one > > > > > > > > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > > > > > > > > was getting errors regardless of the 'cma=256M' or not. > > > > > > > > I don't have a problem using the reserved memory, but I guess I am not > > > > > > > > sure what the amount should be. I know for the video decoding 1080p, > > > > > > > > I have historically used cma=128M, but with the 3D also needing some > > > > > > > > memory allocation, is that enough or should I use 256M? > > > > > > > > > > > > > > > > adam > > > > > > > > > > > > > > -- > > > > > > > Sincerely yours, > > > > > > > Mike. > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > Mike. > > > > > > > > > -- > > Sincerely yours, > > Mike. > > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-03 5:34 ` [PATCH v2 00/21] Refine memblock API Mike Rapoport @ 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 14:46 ` Chris Healy 0 siblings, 2 replies; 13+ messages in thread From: Russell King - ARM Linux admin @ 2019-10-03 8:49 UTC (permalink / raw) To: Mike Rapoport Cc: Adam Ford, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc, Lucas Stach On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > (trimmed the CC) > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > Before the patch: > > > > # cat /sys/kernel/debug/memblock/memory > > 0: 0x10000000..0x8fffffff > > # cat /sys/kernel/debug/memblock/reserved > > 0: 0x10004000..0x10007fff > > 34: 0x2fffff88..0x3fffffff > > > > > > After the patch: > > # cat /sys/kernel/debug/memblock/memory > > 0: 0x10000000..0x8fffffff > > # cat /sys/kernel/debug/memblock/reserved > > 0: 0x10004000..0x10007fff > > 36: 0x80000000..0x8fffffff > > I'm still not convinced that the memblock refactoring didn't uncovered an > issue in etnaviv driver. > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? I think you have that the wrong way round. > BTW, the code that complained about "command buffer outside valid memory > window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: > implement per-process address spaces on MMUv2"). > > Could be that recent changes to MMU management of etnaviv resolve the > issue? The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 hardware requires command buffers within the first 2GiB of physical RAM. I've reported the problem previously but there was no resolution, other than pointing the blame at CMA. https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html#223516 -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-03 8:49 ` Russell King - ARM Linux admin @ 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 13:17 ` Lucas Stach 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-03 14:46 ` Chris Healy 1 sibling, 2 replies; 13+ messages in thread From: Mike Rapoport @ 2019-10-03 11:30 UTC (permalink / raw) To: Russell King - ARM Linux admin Cc: Adam Ford, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc, Lucas Stach On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux admin wrote: > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > (trimmed the CC) > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > Before the patch: > > > > > > # cat /sys/kernel/debug/memblock/memory > > > 0: 0x10000000..0x8fffffff > > > # cat /sys/kernel/debug/memblock/reserved > > > 0: 0x10004000..0x10007fff > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > After the patch: > > > # cat /sys/kernel/debug/memblock/memory > > > 0: 0x10000000..0x8fffffff > > > # cat /sys/kernel/debug/memblock/reserved > > > 0: 0x10004000..0x10007fff > > > 36: 0x80000000..0x8fffffff > > > > I'm still not convinced that the memblock refactoring didn't uncovered an > > issue in etnaviv driver. > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? > > I think you have that the wrong way round. I'm relying on Adam's reports of working and non-working versions. According to that etnaviv works when CMA area is at 0x80000000 and does not work when it is at 0x30000000. He also sent logs a few days ago [1], they also confirm that. [1] https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > BTW, the code that complained about "command buffer outside valid memory > > window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: > > implement per-process address spaces on MMUv2"). > > > > Could be that recent changes to MMU management of etnaviv resolve the > > issue? > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > hardware requires command buffers within the first 2GiB of physical > RAM. I've mentioned that patch because it removed the check for cmdbuf address for MMUv1: @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) PAGE_SIZE); if (ret) { dev_err(gpu->dev, "could not create command buffer\n"); - goto unmap_suballoc; - } - - if (!(gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION) && - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu->cmdbuf_mapping) > 0x80000000) { - ret = -EINVAL; - dev_err(gpu->dev, - "command buffer outside valid memory window\n"); - goto free_buffer; + goto fail; } /* Setup event management */ I really don't know how etnaviv works, so I hoped that people who understand it would help. > I've reported the problem previously but there was no resolution, > other than pointing the blame at CMA. > > https://lists.freedesktop.org/archives/dri-devel/2019-June/thread.html#223516 > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-03 11:30 ` Mike Rapoport @ 2019-10-03 13:17 ` Lucas Stach 2019-10-04 9:27 ` Russell King - ARM Linux admin 1 sibling, 0 replies; 13+ messages in thread From: Lucas Stach @ 2019-10-03 13:17 UTC (permalink / raw) To: Mike Rapoport, Russell King - ARM Linux admin Cc: Adam Ford, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc Am Donnerstag, den 03.10.2019, 14:30 +0300 schrieb Mike Rapoport: > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux admin wrote: > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > (trimmed the CC) > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > Before the patch: > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > 0: 0x10000000..0x8fffffff > > > > # cat /sys/kernel/debug/memblock/reserved > > > > 0: 0x10004000..0x10007fff > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > After the patch: > > > > # cat /sys/kernel/debug/memblock/memory > > > > 0: 0x10000000..0x8fffffff > > > > # cat /sys/kernel/debug/memblock/reserved > > > > 0: 0x10004000..0x10007fff > > > > 36: 0x80000000..0x8fffffff > > > > > > I'm still not convinced that the memblock refactoring didn't uncovered an > > > issue in etnaviv driver. > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? > > > > I think you have that the wrong way round. > > I'm relying on Adam's reports of working and non-working versions. > According to that etnaviv works when CMA area is at 0x80000000 and does not > work when it is at 0x30000000. > > He also sent logs a few days ago [1], they also confirm that. > > [1] https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ To clarify: Etnaviv needs to know where the CMA area is in order to move a aperture window to cover the CMA area so the command buffers allocated in contig memory can be mapped through this aperture. Now the issue is that there is currently there is no good API for a driver to know where the CMA area is located, so we are trying to infer this from dma_get_required_mask. Unfortunately this can overshoot the real DRAM area by a bit, so combined with the fixed 2GB size of the GPU aperture this means we are no longer able to map the command buffers through the required aperture if the CMA area moves too far down in the physical memory. It's really a bad interaction between etnaviv and CMA area placement, due to insufficient APIs to communicate some crucial information. There is nothing in the etnaviv driver or the hardware which requires the CMA area to be at a certain place, we just need to know where it is located exactly. So my try at fixing this [1] was by adding a API to get the required information, but the first attempt was shot down and I hadn't had time to follow up on this yet. Regards, Lucas [1] https://patchwork.kernel.org/patch/10966767/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 13:17 ` Lucas Stach @ 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 13:21 ` Lucas Stach 2019-10-04 17:29 ` Mike Rapoport 1 sibling, 2 replies; 13+ messages in thread From: Russell King - ARM Linux admin @ 2019-10-04 9:27 UTC (permalink / raw) To: Mike Rapoport Cc: Adam Ford, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc, Lucas Stach On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux admin wrote: > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > (trimmed the CC) > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > > > > Before the patch: > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > 0: 0x10000000..0x8fffffff > > > > # cat /sys/kernel/debug/memblock/reserved > > > > 0: 0x10004000..0x10007fff > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > After the patch: > > > > # cat /sys/kernel/debug/memblock/memory > > > > 0: 0x10000000..0x8fffffff > > > > # cat /sys/kernel/debug/memblock/reserved > > > > 0: 0x10004000..0x10007fff > > > > 36: 0x80000000..0x8fffffff > > > > > > I'm still not convinced that the memblock refactoring didn't uncovered an > > > issue in etnaviv driver. > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? > > > > I think you have that the wrong way round. > > I'm relying on Adam's reports of working and non-working versions. > According to that etnaviv works when CMA area is at 0x80000000 and does not > work when it is at 0x30000000. > > He also sent logs a few days ago [1], they also confirm that. > > [1] https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ Sorry, yes, you're right. Still, I've reported this same regression a while back, and it's never gone away. > > > BTW, the code that complained about "command buffer outside valid memory > > > window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: > > > implement per-process address spaces on MMUv2"). > > > > > > Could be that recent changes to MMU management of etnaviv resolve the > > > issue? > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > hardware requires command buffers within the first 2GiB of physical > > RAM. > > I've mentioned that patch because it removed the check for cmdbuf address > for MMUv1: > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > PAGE_SIZE); > if (ret) { > dev_err(gpu->dev, "could not create command buffer\n"); > - goto unmap_suballoc; > - } > - > - if (!(gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION) && > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu->cmdbuf_mapping) > 0x80000000) { > - ret = -EINVAL; > - dev_err(gpu->dev, > - "command buffer outside valid memory window\n"); > - goto free_buffer; > + goto fail; > } > > /* Setup event management */ > > > I really don't know how etnaviv works, so I hoped that people who > understand it would help. From what I can see, removing that check is a completely insane thing to do, and I note that these changes are _not_ described in the commit message. The problem was known about _before_ (June 22) the patch was created (July 5). Lucas, please can you explain why removing the above check, which is well known to correctly trigger on various platforms to prevent incorrect GPU behaviour, is safe? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-04 9:27 ` Russell King - ARM Linux admin @ 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:58 ` Adam Ford 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 1 sibling, 2 replies; 13+ messages in thread From: Lucas Stach @ 2019-10-04 13:21 UTC (permalink / raw) To: Russell King - ARM Linux admin, Mike Rapoport Cc: Adam Ford, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM Linux admin: > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux > > admin wrote: > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > > (trimmed the CC) > > > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport < > > > > > rppt@linux.ibm.com> wrote: > > > > > > > > > > Before the patch: > > > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > 0: 0x10000000..0x8fffffff > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > 0: 0x10004000..0x10007fff > > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > > > > After the patch: > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > 0: 0x10000000..0x8fffffff > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > 0: 0x10004000..0x10007fff > > > > > 36: 0x80000000..0x8fffffff > > > > > > > > I'm still not convinced that the memblock refactoring didn't > > > > uncovered an > > > > issue in etnaviv driver. > > > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it > > > > fail? > > > > > > I think you have that the wrong way round. > > > > I'm relying on Adam's reports of working and non-working versions. > > According to that etnaviv works when CMA area is at 0x80000000 and > > does not > > work when it is at 0x30000000. > > > > He also sent logs a few days ago [1], they also confirm that. > > > > [1] > > https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > Sorry, yes, you're right. Still, I've reported this same regression > a while back, and it's never gone away. > > > > > BTW, the code that complained about "command buffer outside > > > > valid memory > > > > window" has been removed by the commit 17e4660ae3d7 > > > > ("drm/etnaviv: > > > > implement per-process address spaces on MMUv2"). > > > > > > > > Could be that recent changes to MMU management of etnaviv > > > > resolve the > > > > issue? > > > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > > hardware requires command buffers within the first 2GiB of > > > physical > > > RAM. > > > > I've mentioned that patch because it removed the check for cmdbuf > > address > > for MMUv1: > > > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > > PAGE_SIZE); > > if (ret) { > > dev_err(gpu->dev, "could not create command > > buffer\n"); > > - goto unmap_suballoc; > > - } > > - > > - if (!(gpu->identity.minor_features1 & > > chipMinorFeatures1_MMU_VERSION) && > > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu- > > >cmdbuf_mapping) > 0x80000000) { > > - ret = -EINVAL; > > - dev_err(gpu->dev, > > - "command buffer outside valid memory > > window\n"); > > - goto free_buffer; > > + goto fail; > > } > > > > /* Setup event management */ > > > > > > I really don't know how etnaviv works, so I hoped that people who > > understand it would help. > > From what I can see, removing that check is a completely insane thing > to do, and I note that these changes are _not_ described in the > commit > message. The problem was known about _before_ (June 22) the patch > was > created (July 5). > > Lucas, please can you explain why removing the above check, which is > well known to correctly trigger on various platforms to prevent > incorrect GPU behaviour, is safe? It isn't. It's a pretty big oversight in this commit to remove this check. It can't be done at the same spot in the code anymore, as we don't have a mapping context at this time anymore, but it should have moved into etnaviv_iommu_context_init(). I'll send a patch to fix this up. Regards, Lucas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-04 13:21 ` Lucas Stach @ 2019-10-04 13:58 ` Adam Ford 2019-10-04 17:10 ` Mike Rapoport 1 sibling, 0 replies; 13+ messages in thread From: Adam Ford @ 2019-10-04 13:58 UTC (permalink / raw) To: Lucas Stach Cc: Catalin Marinas, Russell King - ARM Linux admin, The etnaviv authors, Linux Kernel Mailing List, Linux Memory Management List, Andrew Morton, Mike Rapoport, Fabio Estevam, Christoph Hellwig, arm-soc On Fri, Oct 4, 2019 at 8:23 AM Lucas Stach <l.stach@pengutronix.de> wrote: > > Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM > Linux admin: > > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux > > > admin wrote: > > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > > > (trimmed the CC) > > > > > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport < > > > > > > rppt@linux.ibm.com> wrote: > > > > > > > > > > > > Before the patch: > > > > > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > > > > > > > After the patch: > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 36: 0x80000000..0x8fffffff > > > > > > > > > > I'm still not convinced that the memblock refactoring didn't > > > > > uncovered an > > > > > issue in etnaviv driver. > > > > > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it > > > > > fail? > > > > > > > > I think you have that the wrong way round. > > > > > > I'm relying on Adam's reports of working and non-working versions. > > > According to that etnaviv works when CMA area is at 0x80000000 and > > > does not > > > work when it is at 0x30000000. > > > > > > He also sent logs a few days ago [1], they also confirm that. > > > > > > [1] > > > https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > > > Sorry, yes, you're right. Still, I've reported this same regression > > a while back, and it's never gone away. > > > > > > > BTW, the code that complained about "command buffer outside > > > > > valid memory > > > > > window" has been removed by the commit 17e4660ae3d7 > > > > > ("drm/etnaviv: > > > > > implement per-process address spaces on MMUv2"). > > > > > > > > > > Could be that recent changes to MMU management of etnaviv > > > > > resolve the > > > > > issue? > > > > > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > > > hardware requires command buffers within the first 2GiB of > > > > physical > > > > RAM. > > > > > > I've mentioned that patch because it removed the check for cmdbuf > > > address > > > for MMUv1: > > > > > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > > > PAGE_SIZE); > > > if (ret) { > > > dev_err(gpu->dev, "could not create command > > > buffer\n"); > > > - goto unmap_suballoc; > > > - } > > > - > > > - if (!(gpu->identity.minor_features1 & > > > chipMinorFeatures1_MMU_VERSION) && > > > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu- > > > >cmdbuf_mapping) > 0x80000000) { > > > - ret = -EINVAL; > > > - dev_err(gpu->dev, > > > - "command buffer outside valid memory > > > window\n"); > > > - goto free_buffer; > > > + goto fail; > > > } > > > > > > /* Setup event management */ > > > > > > > > > I really don't know how etnaviv works, so I hoped that people who > > > understand it would help. > > > > From what I can see, removing that check is a completely insane thing > > to do, and I note that these changes are _not_ described in the > > commit > > message. The problem was known about _before_ (June 22) the patch > > was > > created (July 5). > > > > Lucas, please can you explain why removing the above check, which is > > well known to correctly trigger on various platforms to prevent > > incorrect GPU behaviour, is safe? > > It isn't. It's a pretty big oversight in this commit to remove this > check. It can't be done at the same spot in the code anymore, as we > don't have a mapping context at this time anymore, but it should have > moved into etnaviv_iommu_context_init(). I'll send a patch to fix this > up. If you CC me, I will test it and report my findings. adam > > Regards, > Lucas > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:58 ` Adam Ford @ 2019-10-04 17:10 ` Mike Rapoport 1 sibling, 0 replies; 13+ messages in thread From: Mike Rapoport @ 2019-10-04 17:10 UTC (permalink / raw) To: Lucas Stach Cc: Adam Ford, Russell King - ARM Linux admin, The etnaviv authors, Linux Kernel Mailing List, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc On Fri, Oct 04, 2019 at 03:21:03PM +0200, Lucas Stach wrote: > Am Freitag, den 04.10.2019, 10:27 +0100 schrieb Russell King - ARM > Linux admin: > > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux > > > admin wrote: > > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > > > (trimmed the CC) > > > > > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport < > > > > > > rppt@linux.ibm.com> wrote: > > > > > > > > > > > > Before the patch: > > > > > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > > > > > > > After the patch: > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > > 0: 0x10000000..0x8fffffff > > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > > 0: 0x10004000..0x10007fff > > > > > > 36: 0x80000000..0x8fffffff > > > > > > > > > > I'm still not convinced that the memblock refactoring didn't > > > > > uncovered an > > > > > issue in etnaviv driver. > > > > > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it > > > > > fail? > > > > > > > > I think you have that the wrong way round. > > > > > > I'm relying on Adam's reports of working and non-working versions. > > > According to that etnaviv works when CMA area is at 0x80000000 and > > > does not > > > work when it is at 0x30000000. > > > > > > He also sent logs a few days ago [1], they also confirm that. > > > > > > [1] > > > https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > > > Sorry, yes, you're right. Still, I've reported this same regression > > a while back, and it's never gone away. > > > > > > > BTW, the code that complained about "command buffer outside > > > > > valid memory > > > > > window" has been removed by the commit 17e4660ae3d7 > > > > > ("drm/etnaviv: > > > > > implement per-process address spaces on MMUv2"). > > > > > > > > > > Could be that recent changes to MMU management of etnaviv > > > > > resolve the > > > > > issue? > > > > > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > > > hardware requires command buffers within the first 2GiB of > > > > physical > > > > RAM. > > > > > > I've mentioned that patch because it removed the check for cmdbuf > > > address > > > for MMUv1: > > > > > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > > > PAGE_SIZE); > > > if (ret) { > > > dev_err(gpu->dev, "could not create command > > > buffer\n"); > > > - goto unmap_suballoc; > > > - } > > > - > > > - if (!(gpu->identity.minor_features1 & > > > chipMinorFeatures1_MMU_VERSION) && > > > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu- > > > >cmdbuf_mapping) > 0x80000000) { > > > - ret = -EINVAL; > > > - dev_err(gpu->dev, > > > - "command buffer outside valid memory > > > window\n"); > > > - goto free_buffer; > > > + goto fail; > > > } > > > > > > /* Setup event management */ > > > > > > > > > I really don't know how etnaviv works, so I hoped that people who > > > understand it would help. > > > > From what I can see, removing that check is a completely insane thing > > to do, and I note that these changes are _not_ described in the > > commit > > message. The problem was known about _before_ (June 22) the patch > > was > > created (July 5). > > > > Lucas, please can you explain why removing the above check, which is > > well known to correctly trigger on various platforms to prevent > > incorrect GPU behaviour, is safe? > > It isn't. It's a pretty big oversight in this commit to remove this > check. It can't be done at the same spot in the code anymore, as we > don't have a mapping context at this time anymore, but it should have > moved into etnaviv_iommu_context_init(). I'll send a patch to fix this > up. Lucas, can you make the check use SZ_2G instead of 0x80000000 and add a comment about 2G limitation of the aperture window? > Regards, > Lucas > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 13:21 ` Lucas Stach @ 2019-10-04 17:29 ` Mike Rapoport 1 sibling, 0 replies; 13+ messages in thread From: Mike Rapoport @ 2019-10-04 17:29 UTC (permalink / raw) To: Russell King - ARM Linux admin Cc: Adam Ford, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Catalin Marinas, Andrew Morton, Fabio Estevam, Christoph Hellwig, arm-soc, Lucas Stach On Fri, Oct 04, 2019 at 10:27:27AM +0100, Russell King - ARM Linux admin wrote: > On Thu, Oct 03, 2019 at 02:30:10PM +0300, Mike Rapoport wrote: > > On Thu, Oct 03, 2019 at 09:49:14AM +0100, Russell King - ARM Linux admin wrote: > > > On Thu, Oct 03, 2019 at 08:34:52AM +0300, Mike Rapoport wrote: > > > > (trimmed the CC) > > > > > > > > On Wed, Oct 02, 2019 at 06:14:11AM -0500, Adam Ford wrote: > > > > > On Wed, Oct 2, 2019 at 2:36 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > > > > > > > > > > > > > Before the patch: > > > > > > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > 0: 0x10000000..0x8fffffff > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > 0: 0x10004000..0x10007fff > > > > > 34: 0x2fffff88..0x3fffffff > > > > > > > > > > > > > > > After the patch: > > > > > # cat /sys/kernel/debug/memblock/memory > > > > > 0: 0x10000000..0x8fffffff > > > > > # cat /sys/kernel/debug/memblock/reserved > > > > > 0: 0x10004000..0x10007fff > > > > > 36: 0x80000000..0x8fffffff > > > > > > > > I'm still not convinced that the memblock refactoring didn't uncovered an > > > > issue in etnaviv driver. > > > > > > > > Why moving the CMA area from 0x80000000 to 0x30000000 makes it fail? > > > > > > I think you have that the wrong way round. > > > > I'm relying on Adam's reports of working and non-working versions. > > According to that etnaviv works when CMA area is at 0x80000000 and does not > > work when it is at 0x30000000. > > > > He also sent logs a few days ago [1], they also confirm that. > > > > [1] https://lore.kernel.org/linux-mm/CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com/ > > Sorry, yes, you're right. Still, I've reported this same regression > a while back, and it's never gone away. > > > > > BTW, the code that complained about "command buffer outside valid memory > > > > window" has been removed by the commit 17e4660ae3d7 ("drm/etnaviv: > > > > implement per-process address spaces on MMUv2"). > > > > > > > > Could be that recent changes to MMU management of etnaviv resolve the > > > > issue? > > > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > > hardware requires command buffers within the first 2GiB of physical > > > RAM. > > > > I've mentioned that patch because it removed the check for cmdbuf address > > for MMUv1: > > > > @@ -785,15 +768,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) > > PAGE_SIZE); > > if (ret) { > > dev_err(gpu->dev, "could not create command buffer\n"); > > - goto unmap_suballoc; > > - } > > - > > - if (!(gpu->identity.minor_features1 & chipMinorFeatures1_MMU_VERSION) && > > - etnaviv_cmdbuf_get_va(&gpu->buffer, &gpu->cmdbuf_mapping) > 0x80000000) { > > - ret = -EINVAL; > > - dev_err(gpu->dev, > > - "command buffer outside valid memory window\n"); > > - goto free_buffer; > > + goto fail; > > } > > > > /* Setup event management */ > > > > > > I really don't know how etnaviv works, so I hoped that people who > > understand it would help. > > From what I can see, removing that check is a completely insane thing > to do, and I note that these changes are _not_ described in the commit > message. The problem was known about _before_ (June 22) the patch was > created (July 5). The memblock refactoring went in in 5.1 which was May 5, and likely it caused the regression. Unless I'm missing something, before the memblock refactoring the CMA reservation could use the entire physical memory because memblock_phys_alloc() didn't enforce memblock.current_limit. Since memblock default is to allocate from top, cma_declare_contiguous() could grab the memory close to the end of DRAM and thus have physical address close enough to the virtual address to fit in the 2G limit. When I've made memblock_phys* limit the memblock allocations to memblock.current_limit the CMA area moved too far away down and the gap became larger than 2G. It does not seem like dealing with this in etnaviv driver and DMA and CMA APIs would happen fast and the "revert" of the memblock changes I've sent earlier in this thread does fix the problem. Andrew, would you like me to resend the patch in a separate e-mail? > Lucas, please can you explain why removing the above check, which is > well known to correctly trigger on various platforms to prevent > incorrect GPU behaviour, is safe? > > Thanks. > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 11:30 ` Mike Rapoport @ 2019-10-03 14:46 ` Chris Healy 2019-10-04 9:12 ` Russell King - ARM Linux admin 1 sibling, 1 reply; 13+ messages in thread From: Chris Healy @ 2019-10-03 14:46 UTC (permalink / raw) To: Russell King - ARM Linux admin Cc: Catalin Marinas, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Fabio Estevam, Andrew Morton, Mike Rapoport, Adam Ford, Christoph Hellwig, arm-soc, Lucas Stach > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > hardware requires command buffers within the first 2GiB of physical > RAM. > I thought that the i.MX6q has the MMUv1 and GC2000 GPU while the i.MX6qp has the MMUv2 and GC3000? Meaning the i.MX6 has both MMUv1 and MMUv2 depending on which i.MX6 part we are talking about. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH v2 00/21] Refine memblock API 2019-10-03 14:46 ` Chris Healy @ 2019-10-04 9:12 ` Russell King - ARM Linux admin 0 siblings, 0 replies; 13+ messages in thread From: Russell King - ARM Linux admin @ 2019-10-04 9:12 UTC (permalink / raw) To: Chris Healy Cc: Catalin Marinas, Linux Kernel Mailing List, The etnaviv authors, Linux Memory Management List, Fabio Estevam, Andrew Morton, Mike Rapoport, Adam Ford, Christoph Hellwig, arm-soc, Lucas Stach On Thu, Oct 03, 2019 at 07:46:06AM -0700, Chris Healy wrote: > > > > The iMX6 does not have MMUv2 hardware, it has MMUv1. With MMUv1 > > hardware requires command buffers within the first 2GiB of physical > > RAM. > > > I thought that the i.MX6q has the MMUv1 and GC2000 GPU while the > i.MX6qp has the MMUv2 and GC3000? Meaning the i.MX6 has both MMUv1 > and MMUv2 depending on which i.MX6 part we are talking about. The report says iMX6Q with GC2000 - which is what I was referring to here. I'm not aware of what the later SoCs use, since I've never used them. Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v2 00/21] Refine memblock API @ 2019-01-21 8:03 Mike Rapoport [not found] ` <CAHCN7x+Jv7yGPoB0Gm=TJ30ObLJduw2XomHkd++KqFEURYQcGg@mail.gmail.com> 0 siblings, 1 reply; 13+ messages in thread From: Mike Rapoport @ 2019-01-21 8:03 UTC (permalink / raw) To: linux-mm Cc: Rich Felker, linux-ia64, devicetree, Catalin Marinas, Heiko Carstens, x86, linux-mips, Max Filippov, Guo Ren, sparclinux, Christoph Hellwig, linux-s390, linux-c6x-dev, Yoshinori Sato, Richard Weinberger, linux-sh, Russell King, kasan-dev, Mike Rapoport, Geert Uytterhoeven, Mark Salter, Dennis Zhou, Matt Turner, linux-snps-arc, uclinux-h8-devel, Petr Mladek, linux-xtensa, linux-alpha, linux-um, linux-m68k, Rob Herring, Greentime Hu, xen-devel, Stafford Horne, Guan Xuetao, linux-arm-kernel, Michal Simek, Tony Luck, Greg Kroah-Hartman, linux-usb, linux-kernel, Paul Burton, Vineet Gupta, Michael Ellerman, Andrew Morton, linuxppc-dev, David S. Miller, openrisc Hi, Current memblock API is quite extensive and, which is more annoying, duplicated. Except the low-level functions that allow searching for a free memory region and marking it as reserved, memblock provides three (well, two and a half) sets of functions to allocate memory. There are several overlapping functions that return a physical address and there are functions that return virtual address. Those that return the virtual address may also clear the allocated memory. And, on top of all that, some allocators panic and some return NULL in case of error. This set tries to reduce the mess, and trim down the amount of memblock allocation methods. Patches 1-10 consolidate the functions that return physical address of the allocated memory Patches 11-13 are some trivial cleanups Patches 14-19 add checks for the return value of memblock_alloc*() and panics in case of errors. The patches 14-18 include some minor refactoring to have better readability of the resulting code and patch 19 is a mechanical addition of if (!ptr) panic(); after memblock_alloc*() calls. And, finally, patches 20 and 21 remove panic() calls memblock and _nopanic variants from memblock. v2 changes: * replace some more %lu with %zu * remove panics where they are not needed in s390 and in printk * collect Acked-by and Reviewed-by. Christophe Leroy (1): powerpc: use memblock functions returning virtual address Mike Rapoport (20): openrisc: prefer memblock APIs returning virtual address memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc memblock: drop memblock_alloc_base_nid() memblock: emphasize that memblock_alloc_range() returns a physical address memblock: memblock_phys_alloc_try_nid(): don't panic memblock: memblock_phys_alloc(): don't panic memblock: drop __memblock_alloc_base() memblock: drop memblock_alloc_base() memblock: refactor internal allocation functions memblock: make memblock_find_in_range_node() and choose_memblock_flags() static arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0) arch: don't memset(0) memory returned by memblock_alloc() ia64: add checks for the return value of memblock_alloc*() sparc: add checks for the return value of memblock_alloc*() mm/percpu: add checks for the return value of memblock_alloc*() init/main: add checks for the return value of memblock_alloc*() swiotlb: add checks for the return value of memblock_alloc*() treewide: add checks for the return value of memblock_alloc*() memblock: memblock_alloc_try_nid: don't panic memblock: drop memblock_alloc_*_nopanic() variants arch/alpha/kernel/core_cia.c | 5 +- arch/alpha/kernel/core_marvel.c | 6 + arch/alpha/kernel/pci-noop.c | 13 +- arch/alpha/kernel/pci.c | 11 +- arch/alpha/kernel/pci_iommu.c | 16 +- arch/alpha/kernel/setup.c | 2 +- arch/arc/kernel/unwind.c | 3 +- arch/arc/mm/highmem.c | 4 + arch/arm/kernel/setup.c | 6 + arch/arm/mm/init.c | 6 +- arch/arm/mm/mmu.c | 14 +- arch/arm64/kernel/setup.c | 8 +- arch/arm64/mm/kasan_init.c | 10 ++ arch/arm64/mm/mmu.c | 2 + arch/arm64/mm/numa.c | 4 + arch/c6x/mm/dma-coherent.c | 4 + arch/c6x/mm/init.c | 4 +- arch/csky/mm/highmem.c | 5 + arch/h8300/mm/init.c | 4 +- arch/ia64/kernel/mca.c | 25 +-- arch/ia64/mm/contig.c | 8 +- arch/ia64/mm/discontig.c | 4 + arch/ia64/mm/init.c | 38 ++++- arch/ia64/mm/tlb.c | 6 + arch/ia64/sn/kernel/io_common.c | 3 + arch/ia64/sn/kernel/setup.c | 12 +- arch/m68k/atari/stram.c | 4 + arch/m68k/mm/init.c | 3 + arch/m68k/mm/mcfmmu.c | 7 +- arch/m68k/mm/motorola.c | 9 ++ arch/m68k/mm/sun3mmu.c | 6 + arch/m68k/sun3/sun3dvma.c | 3 + arch/microblaze/mm/init.c | 10 +- arch/mips/cavium-octeon/dma-octeon.c | 3 + arch/mips/kernel/setup.c | 3 + arch/mips/kernel/traps.c | 5 +- arch/mips/mm/init.c | 5 + arch/nds32/mm/init.c | 12 ++ arch/openrisc/mm/init.c | 5 +- arch/openrisc/mm/ioremap.c | 8 +- arch/powerpc/kernel/dt_cpu_ftrs.c | 8 +- arch/powerpc/kernel/irq.c | 5 - arch/powerpc/kernel/paca.c | 6 +- arch/powerpc/kernel/pci_32.c | 3 + arch/powerpc/kernel/prom.c | 5 +- arch/powerpc/kernel/rtas.c | 6 +- arch/powerpc/kernel/setup-common.c | 3 + arch/powerpc/kernel/setup_32.c | 26 ++-- arch/powerpc/kernel/setup_64.c | 4 + arch/powerpc/lib/alloc.c | 3 + arch/powerpc/mm/hash_utils_64.c | 11 +- arch/powerpc/mm/mmu_context_nohash.c | 9 ++ arch/powerpc/mm/numa.c | 4 + arch/powerpc/mm/pgtable-book3e.c | 12 +- arch/powerpc/mm/pgtable-book3s64.c | 3 + arch/powerpc/mm/pgtable-radix.c | 9 +- arch/powerpc/mm/ppc_mmu_32.c | 3 + arch/powerpc/platforms/pasemi/iommu.c | 3 + arch/powerpc/platforms/powermac/nvram.c | 3 + arch/powerpc/platforms/powernv/opal.c | 3 + arch/powerpc/platforms/powernv/pci-ioda.c | 8 + arch/powerpc/platforms/ps3/setup.c | 3 + arch/powerpc/sysdev/dart_iommu.c | 3 + arch/powerpc/sysdev/msi_bitmap.c | 3 + arch/s390/kernel/crash_dump.c | 3 + arch/s390/kernel/setup.c | 16 ++ arch/s390/kernel/smp.c | 9 +- arch/s390/kernel/topology.c | 6 + arch/s390/numa/mode_emu.c | 3 + arch/s390/numa/numa.c | 6 +- arch/sh/boards/mach-ap325rxa/setup.c | 5 +- arch/sh/boards/mach-ecovec24/setup.c | 10 +- arch/sh/boards/mach-kfr2r09/setup.c | 5 +- arch/sh/boards/mach-migor/setup.c | 5 +- arch/sh/boards/mach-se/7724/setup.c | 10 +- arch/sh/kernel/machine_kexec.c | 3 +- arch/sh/mm/init.c | 8 +- arch/sh/mm/numa.c | 4 + arch/sparc/kernel/prom_32.c | 6 +- arch/sparc/kernel/setup_64.c | 6 + arch/sparc/kernel/smp_64.c | 12 ++ arch/sparc/mm/init_32.c | 2 +- arch/sparc/mm/init_64.c | 11 ++ arch/sparc/mm/srmmu.c | 18 ++- arch/um/drivers/net_kern.c | 3 + arch/um/drivers/vector_kern.c | 3 + arch/um/kernel/initrd.c | 2 + arch/um/kernel/mem.c | 16 ++ arch/unicore32/kernel/setup.c | 4 + arch/unicore32/mm/mmu.c | 15 +- arch/x86/kernel/acpi/boot.c | 3 + arch/x86/kernel/apic/io_apic.c | 5 + arch/x86/kernel/e820.c | 5 +- arch/x86/kernel/setup_percpu.c | 10 +- arch/x86/mm/kasan_init_64.c | 14 +- arch/x86/mm/numa.c | 12 +- arch/x86/platform/olpc/olpc_dt.c | 3 + arch/x86/xen/p2m.c | 11 +- arch/xtensa/mm/kasan_init.c | 10 +- arch/xtensa/mm/mmu.c | 3 + drivers/clk/ti/clk.c | 3 + drivers/firmware/memmap.c | 2 +- drivers/macintosh/smu.c | 5 +- drivers/of/fdt.c | 8 +- drivers/of/of_reserved_mem.c | 7 +- drivers/of/unittest.c | 8 +- drivers/usb/early/xhci-dbc.c | 2 +- drivers/xen/swiotlb-xen.c | 7 +- include/linux/memblock.h | 59 +------ init/main.c | 26 +++- kernel/dma/swiotlb.c | 21 ++- kernel/power/snapshot.c | 3 + kernel/printk/printk.c | 9 +- lib/cpumask.c | 3 + mm/cma.c | 10 +- mm/kasan/init.c | 10 +- mm/memblock.c | 249 ++++++++++-------------------- mm/page_alloc.c | 10 +- mm/page_ext.c | 2 +- mm/percpu.c | 84 +++++++--- mm/sparse.c | 25 ++- 121 files changed, 860 insertions(+), 412 deletions(-) -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <CAHCN7x+Jv7yGPoB0Gm=TJ30ObLJduw2XomHkd++KqFEURYQcGg@mail.gmail.com>]
* Re: [PATCH v2 00/21] Refine memblock API [not found] ` <CAHCN7x+Jv7yGPoB0Gm=TJ30ObLJduw2XomHkd++KqFEURYQcGg@mail.gmail.com> @ 2019-09-25 6:42 ` Mike Rapoport 0 siblings, 0 replies; 13+ messages in thread From: Mike Rapoport @ 2019-09-25 6:42 UTC (permalink / raw) To: Adam Ford Cc: Linux Kernel Mailing List, etnaviv, linux-mm, Russell King, linux-arm-kernel, Lucas Stach (updated CC) Hi, On Tue, Sep 24, 2019 at 12:52:35PM -0500, Adam Ford wrote: > On Mon, Jan 21, 2019 at 2:05 AM Mike Rapoport <rppt@linux.ibm.com> wrote: > > > > Hi, > > > > v2 changes: > > * replace some more %lu with %zu > > * remove panics where they are not needed in s390 and in printk > > * collect Acked-by and Reviewed-by. > > > > > > Christophe Leroy (1): > > powerpc: use memblock functions returning virtual address > > > > Mike Rapoport (20): > > openrisc: prefer memblock APIs returning virtual address > > memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc > > memblock: drop memblock_alloc_base_nid() > > memblock: emphasize that memblock_alloc_range() returns a physical address > > memblock: memblock_phys_alloc_try_nid(): don't panic > > memblock: memblock_phys_alloc(): don't panic > > memblock: drop __memblock_alloc_base() > > memblock: drop memblock_alloc_base() > > memblock: refactor internal allocation functions > > memblock: make memblock_find_in_range_node() and choose_memblock_flags() static > > arch: use memblock_alloc() instead of memblock_alloc_from(size, align, 0) > > arch: don't memset(0) memory returned by memblock_alloc() > > ia64: add checks for the return value of memblock_alloc*() > > sparc: add checks for the return value of memblock_alloc*() > > mm/percpu: add checks for the return value of memblock_alloc*() > > init/main: add checks for the return value of memblock_alloc*() > > swiotlb: add checks for the return value of memblock_alloc*() > > treewide: add checks for the return value of memblock_alloc*() > > memblock: memblock_alloc_try_nid: don't panic > > memblock: drop memblock_alloc_*_nopanic() variants > > > I know it's rather late, but this patch broke the Etnaviv 3D graphics > in my i.MX6Q. Can you identify the exact patch from the series that caused the regression? > When I try to use the 3D, it returns some errors and the dmesg log > shows some memory allocation errors too: > [ 3.682347] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) > [ 3.688669] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) > [ 3.695099] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) > [ 3.700800] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108 > [ 3.723013] etnaviv-gpu 130000.gpu: command buffer outside valid > memory window > [ 3.731308] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 > [ 3.752437] etnaviv-gpu 134000.gpu: command buffer outside valid > memory window > [ 3.760583] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 > [ 3.766766] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 > [ 3.776131] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 0 > > # glmark2-es2-drm > Error creating gpu > Error: eglCreateWindowSurface failed with error: 0x3009 > Error: eglCreateWindowSurface failed with error: 0x3009 > Error: CanvasGeneric: Invalid EGL state > Error: main: Could not initialize canvas > > > Before this patch: > > [ 3.691995] etnaviv etnaviv: bound 130000.gpu (ops gpu_ops) > [ 3.698356] etnaviv etnaviv: bound 134000.gpu (ops gpu_ops) > [ 3.704792] etnaviv etnaviv: bound 2204000.gpu (ops gpu_ops) > [ 3.710488] etnaviv-gpu 130000.gpu: model: GC2000, revision: 5108 > [ 3.733649] etnaviv-gpu 134000.gpu: model: GC320, revision: 5007 > [ 3.756115] etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215 > [ 3.762250] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 > [ 3.771432] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on minor 0 > > and the 3D gemos work without this. > > I don't know enough about the i.MX6 nor the 3D accelerator to know how > to fix it. > I am hoping someone in the know might have some suggestions. Can you please add "memblock=debug" to your kernel command line and send kernel logs for both working and failing versions? -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-10-04 17:29 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAHCN7xJdzEppn8-74SvzACsA25bUHGdV7v=CfS08xzSi59Z2uw@mail.gmail.com> [not found] ` <CAOMZO5D2uzR6Sz1QnX3G-Ce_juxU-0PO_vBZX+nR1mpQB8s8-w@mail.gmail.com> [not found] ` <CAHCN7xJ32BYZu-DVTVLSzv222U50JDb8F0A_tLDERbb8kPdRxg@mail.gmail.com> [not found] ` <20190926160433.GD32311@linux.ibm.com> [not found] ` <CAHCN7xL1sFXDhKUpj04d3eDZNgLA1yGAOqwEeCxedy1Qm-JOfQ@mail.gmail.com> [not found] ` <20190928073331.GA5269@linux.ibm.com> [not found] ` <CAHCN7xJEvS2Si=M+BYtz+kY0M4NxmqDjiX9Nwq6_3GGBh3yg=w@mail.gmail.com> [not found] ` <CAHCN7xKLhWw4P9-sZKXQcfSfh2r3J_+rLxuxACW0UVgimCzyVw@mail.gmail.com> [not found] ` <20191002073605.GA30433@linux.ibm.com> [not found] ` <CAHCN7xL1MkJh44N3W_1+08DHmX__SqnfH6dqUzYzr2Wpg0kQyQ@mail.gmail.com> 2019-10-03 5:34 ` [PATCH v2 00/21] Refine memblock API Mike Rapoport 2019-10-03 8:49 ` Russell King - ARM Linux admin 2019-10-03 11:30 ` Mike Rapoport 2019-10-03 13:17 ` Lucas Stach 2019-10-04 9:27 ` Russell King - ARM Linux admin 2019-10-04 13:21 ` Lucas Stach 2019-10-04 13:58 ` Adam Ford 2019-10-04 17:10 ` Mike Rapoport 2019-10-04 17:29 ` Mike Rapoport 2019-10-03 14:46 ` Chris Healy 2019-10-04 9:12 ` Russell King - ARM Linux admin 2019-01-21 8:03 Mike Rapoport [not found] ` <CAHCN7x+Jv7yGPoB0Gm=TJ30ObLJduw2XomHkd++KqFEURYQcGg@mail.gmail.com> 2019-09-25 6:42 ` Mike Rapoport
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).