From: Matthias Brugger <mbrugger@suse.com> To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>, Qian Cai <cai@lca.pw>, catalin.marinas@arm.com Cc: f.fainelli@gmail.com, marc.zyngier@arm.com, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org, m.szyprowski@samsung.com, Robin Murphy <Robin.Murphy@arm.com>, phill@raspberrypi.org, will@kernel.org, Christoph Hellwig <hch@lst.de>, linux-arm-kernel@lists.infradead.org, wahrenst@gmx.net Subject: Re: [PATCH v6 3/4] arm64: use both ZONE_DMA and ZONE_DMA32 Date: Wed, 23 Oct 2019 09:11:59 +0200 [thread overview] Message-ID: <796c6b37-67a0-9598-a146-5f298e0cd0c1@suse.com> (raw) In-Reply-To: <1956a2c8f4911b2a7e2ba3c53506c0f06efb93f8.camel@suse.de> On 22/10/2019 13:23, Nicolas Saenz Julienne wrote: > On Mon, 2019-10-21 at 16:36 -0400, Qian Cai wrote: >> I managed to get more information here, >> >> [ 0.000000] cma: dma_contiguous_reserve(limit c0000000) >> [ 0.000000] cma: dma_contiguous_reserve: reserving 64 MiB for global area >> [ 0.000000] cma: cma_declare_contiguous(size 0x0000000004000000, base >> 0x0000000000000000, limit 0x00000000c0000000 alignment 0x0000000000000000) >> [ 0.000000] cma: Failed to reserve 512 MiB >> >> Full dmesg: >> >> https://cailca.github.io/files/dmesg.txt > > OK I got it, reproduced it too. > > Here are the relevant logs: > > [ 0.000000] DMA [mem 0x00000000802f0000-0x00000000bfffffff] > [ 0.000000] DMA32 [mem 0x00000000c0000000-0x00000000ffffffff] > [ 0.000000] Normal [mem 0x0000000100000000-0x00000097fcffffff] > > As you can see ZONE_DMA spans from 0x00000000802f0000-0x00000000bfffffff which > is slightly smaller than 1GB. > > [ 0.000000] crashkernel reserved: 0x000000009fe00000 - 0x00000000bfe00000 (512 MB) > > Here crashkernel reserved 512M in ZONE_DMA. > > [ 0.000000] cma: Failed to reserve 512 MiB > > CMA tried to allocate 512M in ZONE_DMA which fails as there is no enough space. > Makes sense. > > A fix could be moving crashkernel reservations after CMA and then if unable to > fit in ZONE_DMA try ZONE_DMA32 before bailing out. Maybe it's a little over the > top, yet although most devices will be fine with ZONE_DMA32, the RPi4 needs > crashkernel to be reserved in ZONE_DMA. > > My knowledge of Kdump is limited, so I'd love to see what Catalin has to say. > Here's a tested patch of what I'm proposing: > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index 120c26af916b..49f3c3a34ae2 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -76,6 +76,7 @@ phys_addr_t arm64_dma32_phys_limit __ro_after_init; > static void __init reserve_crashkernel(void) > { > unsigned long long crash_base, crash_size; > + phys_addr_t limit = arm64_dma_phys_limit; > int ret; > > ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(), > @@ -86,11 +87,14 @@ static void __init reserve_crashkernel(void) > > crash_size = PAGE_ALIGN(crash_size); > > +again: > if (crash_base == 0) { > /* Current arm64 boot protocol requires 2MB alignment */ > - crash_base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT, > - crash_size, SZ_2M); > - if (crash_base == 0) { > + crash_base = memblock_find_in_range(0, limit, crash_size, > SZ_2M); > + if (!crash_base && limit == arm64_dma_phys_limit) { > + limit = arm64_dma32_phys_limit; > + goto again; I'd try to avoid the goto. Apart from that we should write some information message that the crashkernel got reserved in arm64_dma_phys_limit. Otherwise RPi4 might break silently and this will give the user at least a hint what happened. Regards, Matthias > + } else if (!crash_base && limit == arm64_dma32_phys_limit) { > pr_warn("cannot allocate crashkernel (size:0x%llx)\n", > crash_size); > return; > @@ -448,13 +452,13 @@ void __init arm64_memblock_init(void) > else > arm64_dma32_phys_limit = PHYS_MASK + 1; > > - reserve_crashkernel(); > - > reserve_elfcorehdr(); > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1; > > dma_contiguous_reserve(arm64_dma_phys_limit ? : arm64_dma32_phys_limit); > + > + reserve_crashkernel(); > } > > void __init bootmem_init(void) > > > Regards, > Nicolas >
WARNING: multiple messages have this Message-ID (diff)
From: Matthias Brugger <mbrugger@suse.com> To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>, Qian Cai <cai@lca.pw>, catalin.marinas@arm.com Cc: f.fainelli@gmail.com, wahrenst@gmx.net, marc.zyngier@arm.com, will@kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Rob Herring <robh+dt@kernel.org>, linux-rpi-kernel@lists.infradead.org, phill@raspberrypi.org, Robin Murphy <Robin.Murphy@arm.com>, Christoph Hellwig <hch@lst.de>, linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com Subject: Re: [PATCH v6 3/4] arm64: use both ZONE_DMA and ZONE_DMA32 Date: Wed, 23 Oct 2019 09:11:59 +0200 [thread overview] Message-ID: <796c6b37-67a0-9598-a146-5f298e0cd0c1@suse.com> (raw) In-Reply-To: <1956a2c8f4911b2a7e2ba3c53506c0f06efb93f8.camel@suse.de> On 22/10/2019 13:23, Nicolas Saenz Julienne wrote: > On Mon, 2019-10-21 at 16:36 -0400, Qian Cai wrote: >> I managed to get more information here, >> >> [ 0.000000] cma: dma_contiguous_reserve(limit c0000000) >> [ 0.000000] cma: dma_contiguous_reserve: reserving 64 MiB for global area >> [ 0.000000] cma: cma_declare_contiguous(size 0x0000000004000000, base >> 0x0000000000000000, limit 0x00000000c0000000 alignment 0x0000000000000000) >> [ 0.000000] cma: Failed to reserve 512 MiB >> >> Full dmesg: >> >> https://cailca.github.io/files/dmesg.txt > > OK I got it, reproduced it too. > > Here are the relevant logs: > > [ 0.000000] DMA [mem 0x00000000802f0000-0x00000000bfffffff] > [ 0.000000] DMA32 [mem 0x00000000c0000000-0x00000000ffffffff] > [ 0.000000] Normal [mem 0x0000000100000000-0x00000097fcffffff] > > As you can see ZONE_DMA spans from 0x00000000802f0000-0x00000000bfffffff which > is slightly smaller than 1GB. > > [ 0.000000] crashkernel reserved: 0x000000009fe00000 - 0x00000000bfe00000 (512 MB) > > Here crashkernel reserved 512M in ZONE_DMA. > > [ 0.000000] cma: Failed to reserve 512 MiB > > CMA tried to allocate 512M in ZONE_DMA which fails as there is no enough space. > Makes sense. > > A fix could be moving crashkernel reservations after CMA and then if unable to > fit in ZONE_DMA try ZONE_DMA32 before bailing out. Maybe it's a little over the > top, yet although most devices will be fine with ZONE_DMA32, the RPi4 needs > crashkernel to be reserved in ZONE_DMA. > > My knowledge of Kdump is limited, so I'd love to see what Catalin has to say. > Here's a tested patch of what I'm proposing: > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > index 120c26af916b..49f3c3a34ae2 100644 > --- a/arch/arm64/mm/init.c > +++ b/arch/arm64/mm/init.c > @@ -76,6 +76,7 @@ phys_addr_t arm64_dma32_phys_limit __ro_after_init; > static void __init reserve_crashkernel(void) > { > unsigned long long crash_base, crash_size; > + phys_addr_t limit = arm64_dma_phys_limit; > int ret; > > ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(), > @@ -86,11 +87,14 @@ static void __init reserve_crashkernel(void) > > crash_size = PAGE_ALIGN(crash_size); > > +again: > if (crash_base == 0) { > /* Current arm64 boot protocol requires 2MB alignment */ > - crash_base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT, > - crash_size, SZ_2M); > - if (crash_base == 0) { > + crash_base = memblock_find_in_range(0, limit, crash_size, > SZ_2M); > + if (!crash_base && limit == arm64_dma_phys_limit) { > + limit = arm64_dma32_phys_limit; > + goto again; I'd try to avoid the goto. Apart from that we should write some information message that the crashkernel got reserved in arm64_dma_phys_limit. Otherwise RPi4 might break silently and this will give the user at least a hint what happened. Regards, Matthias > + } else if (!crash_base && limit == arm64_dma32_phys_limit) { > pr_warn("cannot allocate crashkernel (size:0x%llx)\n", > crash_size); > return; > @@ -448,13 +452,13 @@ void __init arm64_memblock_init(void) > else > arm64_dma32_phys_limit = PHYS_MASK + 1; > > - reserve_crashkernel(); > - > reserve_elfcorehdr(); > > high_memory = __va(memblock_end_of_DRAM() - 1) + 1; > > dma_contiguous_reserve(arm64_dma_phys_limit ? : arm64_dma32_phys_limit); > + > + reserve_crashkernel(); > } > > void __init bootmem_init(void) > > > Regards, > Nicolas > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-23 7:12 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-11 18:25 [PATCH v6 0/4] Raspberry Pi 4 DMA addressing support Nicolas Saenz Julienne 2019-09-11 18:25 ` Nicolas Saenz Julienne 2019-09-11 18:25 ` [PATCH v6 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() Nicolas Saenz Julienne 2019-09-11 18:25 ` Nicolas Saenz Julienne 2019-09-11 18:25 ` [PATCH v6 2/4] arm64: rename variables used to calculate ZONE_DMA32's size Nicolas Saenz Julienne 2019-09-11 18:25 ` Nicolas Saenz Julienne 2019-09-11 18:25 ` [PATCH v6 3/4] arm64: use both ZONE_DMA and ZONE_DMA32 Nicolas Saenz Julienne 2019-09-11 18:25 ` Nicolas Saenz Julienne 2019-10-21 14:15 ` Qian Cai 2019-10-21 14:15 ` Qian Cai 2019-10-21 14:34 ` Nicolas Saenz Julienne 2019-10-21 14:34 ` Nicolas Saenz Julienne 2019-10-21 14:34 ` Nicolas Saenz Julienne 2019-10-21 14:46 ` Qian Cai 2019-10-21 14:46 ` Qian Cai 2019-10-21 17:01 ` Nicolas Saenz Julienne 2019-10-21 17:01 ` Nicolas Saenz Julienne 2019-10-21 17:01 ` Nicolas Saenz Julienne 2019-10-21 17:25 ` Qian Cai 2019-10-21 17:25 ` Qian Cai 2019-10-21 17:55 ` Nicolas Saenz Julienne 2019-10-21 17:55 ` Nicolas Saenz Julienne 2019-10-21 17:55 ` Nicolas Saenz Julienne 2019-10-21 20:36 ` Qian Cai 2019-10-21 20:36 ` Qian Cai 2019-10-22 11:23 ` Nicolas Saenz Julienne 2019-10-22 11:23 ` Nicolas Saenz Julienne 2019-10-22 11:23 ` Nicolas Saenz Julienne 2019-10-23 7:11 ` Matthias Brugger [this message] 2019-10-23 7:11 ` Matthias Brugger 2019-10-31 15:51 ` Catalin Marinas 2019-10-31 15:51 ` Catalin Marinas 2019-10-31 16:04 ` Nicolas Saenz Julienne 2019-10-31 16:04 ` Nicolas Saenz Julienne 2019-10-31 16:04 ` Nicolas Saenz Julienne 2019-10-31 18:02 ` Catalin Marinas 2019-10-31 18:02 ` Catalin Marinas 2019-10-31 18:11 ` Nicolas Saenz Julienne 2019-10-31 18:11 ` Nicolas Saenz Julienne 2019-10-31 18:11 ` Nicolas Saenz Julienne 2019-10-31 18:13 ` Catalin Marinas 2019-10-31 18:13 ` Catalin Marinas 2019-12-03 5:08 ` John Stultz 2019-12-03 5:08 ` John Stultz 2019-12-03 5:08 ` John Stultz 2019-12-03 5:38 ` John Stultz 2019-12-03 5:38 ` John Stultz 2019-12-03 5:38 ` John Stultz 2019-12-03 6:03 ` John Stultz 2019-12-03 6:03 ` John Stultz 2019-12-03 6:03 ` John Stultz 2019-12-03 10:12 ` Will Deacon 2019-12-03 10:12 ` Will Deacon 2019-12-03 11:19 ` Catalin Marinas 2019-12-03 11:19 ` Catalin Marinas 2019-09-11 18:25 ` [PATCH v6 4/4] mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type' Nicolas Saenz Julienne 2019-09-11 18:25 ` Nicolas Saenz Julienne 2019-10-01 16:05 ` [PATCH v6 0/4] Raspberry Pi 4 DMA addressing support Catalin Marinas 2019-10-01 16:05 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=796c6b37-67a0-9598-a146-5f298e0cd0c1@suse.com \ --to=mbrugger@suse.com \ --cc=Robin.Murphy@arm.com \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=f.fainelli@gmail.com \ --cc=hch@lst.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-rpi-kernel@lists.infradead.org \ --cc=m.szyprowski@samsung.com \ --cc=marc.zyngier@arm.com \ --cc=nsaenzjulienne@suse.de \ --cc=phill@raspberrypi.org \ --cc=robh+dt@kernel.org \ --cc=wahrenst@gmx.net \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.