On Thu, Feb 27, 2020 at 9:48 AM Catalin Marinas [off-list ref] wrote:

On Thu, Feb 27, 2020 at 10:56:12AM +0100, Vlastimil Babka wrote:

quoted

On 2/22/20 12:42 AM, Jonathan Richardson wrote:

quoted

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)?

This is stingray (arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts).
cma is specified on cmdline as "cma=1G". The full boot log was in the
attachment.

Do

you use a fixed base? Also, do you want the CMA in ZONE_DMA or
ZONE_DMA32?

I'm not sure which zone we want it in. I'm assuming ZONE_DMA32. Before
that change there was only one zone. If I disable ZONE_DMA I don't see
the error, though I haven't tested anything. I don't really understand why
ZONE_DMA is enabled by default if it's a requirement for Rpi only. I'm
assuming it should work as is with both zones enabled but not clear how
cma spans the two zones. Was there a reason for having both zones
enabled as the default?

quoted

quoted

[    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.

Yes it fails here.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel