All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas saenz julienne <nsaenz@kernel.org>
To: Stefan Wahren <stefan.wahren@i2se.com>,
	Maxime Ripard <maxime@cerno.tech>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: vc4_bo_create: Failed to allocate from CMA
Date: Thu, 17 Jun 2021 11:36:34 +0200	[thread overview]
Message-ID: <6e658588097ef8d864a7347b93a0d2b5d75c18b9.camel@kernel.org> (raw)
In-Reply-To: <e4374e18-2c81-a743-e387-f2512910314d@i2se.com>

On Sat, 2021-06-12 at 17:17 +0200, Stefan Wahren wrote:
> Hi,
> 
> while testing the mainline kernel (arm64, defconfig) on Raspberry Pi 3 B
> Plus with Raspberry Pi OS - 64 bit, sometimes X doesn't start into
> desktop properly (unexpected and unusable login screen instead of auto
> login or mouse pointer is show shorty and than switch back to black
> screen in a loop). In that case dmesg shows the following:
> 
> [   74.737106] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
> CMA:
> [   74.737558] vc4-drm soc:gpu: [drm]                            V3D: 
> 28976kb BOs (10)
> [   74.737602] vc4-drm soc:gpu: [drm]                     V3D
> shader:     44kb BOs (11)
> [   74.737632] vc4-drm soc:gpu: [drm]                           dumb:  
> 4564kb BOs (5)
> [   74.737664] vc4-drm soc:gpu: [drm]                         binner: 
> 16384kb BOs (1)
> [   74.737697] vc4-drm soc:gpu: [drm]                total purged
> BO:      4kb BOs (1)
> [   74.739039] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
> CMA:
> [   74.739466] vc4-drm soc:gpu: [drm]                            V3D: 
> 28972kb BOs (9)
> [   74.739512] vc4-drm soc:gpu: [drm]                     V3D
> shader:     44kb BOs (11)
> [   74.739541] vc4-drm soc:gpu: [drm]                           dumb:  
> 4564kb BOs (5)
> [   74.739570] vc4-drm soc:gpu: [drm]                         binner: 
> 16384kb BOs (1)
> [   74.739602] vc4-drm soc:gpu: [drm]                total purged
> BO:      4kb BOs (1)
> [   74.740718] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from
> CMA:
> [   74.741138] vc4-drm soc:gpu: [drm]                            V3D: 
> 28972kb BOs (9)
> [   74.741171] vc4-drm soc:gpu: [drm]                     V3D
> shader:     44kb BOs (11)
> [   74.741202] vc4-drm soc:gpu: [drm]                           dumb:  
> 4564kb BOs (5)
> [   74.741231] vc4-drm soc:gpu: [drm]                         binner: 
> 16384kb BOs (1)
> [   74.741263] vc4-drm soc:gpu: [drm]                total purged
> BO:      4kb BOs (1)
> ...
> 
> I have only seen this issue on arm64 with latest mainline kernel
> (5.13.0-rc5-00130-gf21b807c3cf8), but also with older kernel versions.
> So it's not a regression. It seems 64 bit needs more CMA.
> 
> In case X started properly i was also able to reproduce these errors
> above by dis- and reconneting HDMI.
> 
> So i increased CMA in bcm283x.dtsi and the problem disappeared:
> 
> iff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index b83a864..d1304cb 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -37,7 +37,7 @@
>  
>          cma: linux,cma {
>              compatible = "shared-dma-pool";
> -            size = <0x4000000>; /* 64MB */
> +            size = <0x6000000>; /* 96MB */
>              reusable;
>              linux,cma-default;
>          };
> 
> The questions are:
> 
> Is this the right way (tm) to fix this problem?

Frankly I don't know if there is a better way. IIRC opensuse and downstream use
DT overlays to cater for this limitation. It seems reasonable to bump the
value. But it'll be in detriment of users that don't care much for graphical
interfaces. Nonetheless, I'm not familiar with how DRM handles CMA/DMA memory.
So let me have a look at it. Maybe there is a SW fix. At first glance I'm
surprised they can't defer to normal page allocations when CMA isn't capable of
honoring the request (like the dma code does).

> And what is a sensible value (don't have a 4K display to test)?

The default for downstream is 256MB. But I've read discussions in the forum
where people needed even more. IIUC it's use-case dependent, resolution is only
one variable, you might then try to run a game and run out of memory there.

Regards,
Nicolas


  reply	other threads:[~2021-06-17  9:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-12 15:17 vc4_bo_create: Failed to allocate from CMA Stefan Wahren
2021-06-17  9:36 ` nicolas saenz julienne [this message]
2021-06-17 10:27   ` Daniel Stone
2021-06-17 17:54   ` Stefan Wahren

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=6e658588097ef8d864a7347b93a0d2b5d75c18b9.camel@kernel.org \
    --to=nsaenz@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maxime@cerno.tech \
    --cc=stefan.wahren@i2se.com \
    /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: link
Be 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.