On Thu, Feb 27, 2020 at 10:56:12AM +0100, Vlastimil Babka wrote:
> On 2/22/20 12:42 AM, Jonathan Richardson wrote:
> > As of the 5.5 kernel I see boot errors in cma. It reserves 1G and then can't
> > activate an area. I added some prints. It's trying to activate the DMA
> > zone. This causes a driver to fail allocating a dma pool later on. The
> > coherent pool is the default 256MB. If I reduce cma from 1G to 512M
> > then it only tries activates DMA32 zone. I assume there was not enough cma
> > memory for DMA zone? Are there any configuration changes required due
> > to the DMA_ZONE and DMA_ZONE32 changes? I've attached my boot log.
>
> I think this question is better for the ARM guys. CC'd
With commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32"), we
limited ZONE_DMA to 1G to accommodate the RPi4 requirements. ZONE_DMA32
spans to the end of the 32-bit space. So with a CMA region that goes
across the 1st GB, you'd hit this problem.
The dma_contiguous_reserve() call in arm64 uses ZONE_DMA32 as the upper
limit under the assumption that you don't need CMA in ZONE_DMA. But this
one doesn't have a lower limit.
What platform is this and how to you request the CMA size (cmdline)? Do
you use a fixed base? Also, do you want the CMA in ZONE_DMA or
ZONE_DMA32?
> > [ 0.000000] cma: Reserved 1024 MiB at 0x00000000a0000000
> > ...
> > [ 0.390448] Activating cma name: reserved, zone name: DMA
> > [ 0.396564] pfn = 0xa0000
> > [ 0.399522] cma->count = 262144
> > [ 0.406244] pfn failed on = c0000
> > [ 0.410002] cma: CMA area reserved could not be activated
> >
> > static int __init cma_activate_area(struct cma *cma)
> > {
> > ...
> > printk("Activating cma name: %s, zone name: %s\n", cma->name, zone->name);
> > printk("pfn = 0x%lx\n", pfn);
> > printk("cma->count = %lu\n", cma->count);
> >
> > do {
> > unsigned j;
> >
> > base_pfn = pfn;
> > for (j = pageblock_nr_pages; j; --j, pfn++) {
> > WARN_ON_ONCE(!pfn_valid(pfn));
> > /*
> > * alloc_contig_range requires the pfn range
> > * specified to be in the same zone. Make this
> > * simple by forcing the entire CMA resv range
> > * to be in the same zone.
> > */
> > if (page_zone(pfn_to_page(pfn)) != zone) {
> > printk("pfn failed on = 0x%lx\n", pfn);
> > goto not_in_zone;
So I guess it's this test that fails as the CMA now spans ZONE_DMA and
ZONE_DMA32.
> > }
> > }
> > init_cma_reserved_pageblock(pfn_to_page(base_pfn));
> > } while (--i);
> >
> > Thanks.
--
Catalin
