gounthar
Posts: 28
Joined: Mon Jul 29, 2013 1:39 pm

GPU memory problem

Tue Sep 25, 2018 8:39 am

Hi,

a friend of mine has a really nice development environment based on ArchLinux, so I thought I could give it a try with the 3B+.
I almost installed everything, but I am facing some memory issue:

Code: Select all

[   55.989445] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   56.006893] [drm]                         kernel:   8100kb BOs (1)
[   56.023581] [drm]                            V3D:  50824kb BOs (19)
[   56.040312] [drm]                     V3D shader:     80kb BOs (20)
[   56.056912] [drm]                           dumb:     48kb BOs (3)
[   56.073536] [drm]                total purged BO:    264kb BOs (7)
[   56.090483] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   56.107844] [drm]                         kernel:   8100kb BOs (1)
[   56.124491] [drm]                            V3D:  50824kb BOs (19)
[   56.141166] [drm]                     V3D shader:     80kb BOs (20)
[   56.157832] [drm]                           dumb:     48kb BOs (3)
[   56.174388] [drm]                total purged BO:    264kb BOs (7)
I changed (ok, wild guesses) a few parameters, but I still have the problem:

Code: Select all

cat /boot/cmdline.txt
coherent_pool=6M smsc95xx.turbo_mode=N cma=128
poddingue in ~ at numeriquelles ➜ cat /boot/config.txt
enable_uart=1
gpu_mem=128
cma_lwm=16
cma_hwm=256
Would you have any suggestion?

Thanks.
2*3B at home for the kids
7*3B+ at work for serious business (gitlab-runner, broadcasting conference, openSTF server...)
Hoping to get a few hats in the following weeks

cjan
Posts: 885
Joined: Sun May 06, 2012 12:00 am

Re: GPU memory problem

Tue Sep 25, 2018 12:46 pm

to my knowledge, enable VC4 drive no need to add gpu_mem & cma.

gounthar
Posts: 28
Joined: Mon Jul 29, 2013 1:39 pm

Re: GPU memory problem

Tue Sep 25, 2018 1:28 pm

Thanks.
So, should I add something like that in config.txt?

Code: Select all

dtoverlay=vc4-kms-v3d
Probably not, as I got:

Code: Select all

[   30.204209] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
[   30.217054] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   30.224165] [drm]                         kernel:   8100kb BOs (1)
[   30.230528] [drm]                            V3D:  49704kb BOs (15)
[   30.236915] [drm]                     V3D shader:     56kb BOs (14)
[   30.243352] [drm]                           dumb:     48kb BOs (3)
[   30.249664] [drm]                total purged BO:     12kb BOs (3)
Thanks.
2*3B at home for the kids
7*3B+ at work for serious business (gitlab-runner, broadcasting conference, openSTF server...)
Hoping to get a few hats in the following weeks

gounthar
Posts: 28
Joined: Mon Jul 29, 2013 1:39 pm

Re: GPU memory problem

Wed Oct 03, 2018 4:20 pm

Sorry to bump this thread...
I am supposed to lead a small workshop at the University next week regarding collaborative development with a limited budget.
I'm ready for the Raspberry Pi Gitlab-ce server, Raspberry Pi Gitlab-ci runner, but I'm stuck with this Raspberry Pi development machine...
I know it was a bit ambitious for this machine running Atom/i3wm and so on, and I even don't know if this could work regarding memory constraints and my ArchLInux/Raspberry knowledge, but I'd like to go to the end... so that I know it could work (or not).
Could anyone give me a hint?
Thanks.
2*3B at home for the kids
7*3B+ at work for serious business (gitlab-runner, broadcasting conference, openSTF server...)
Hoping to get a few hats in the following weeks

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27084
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPU memory problem

Thu Oct 04, 2018 9:25 am

gounthar wrote:
Wed Oct 03, 2018 4:20 pm
Sorry to bump this thread...
I am supposed to lead a small workshop at the University next week regarding collaborative development with a limited budget.
I'm ready for the Raspberry Pi Gitlab-ce server, Raspberry Pi Gitlab-ci runner, but I'm stuck with this Raspberry Pi development machine...
I know it was a bit ambitious for this machine running Atom/i3wm and so on, and I even don't know if this could work regarding memory constraints and my ArchLInux/Raspberry knowledge, but I'd like to go to the end... so that I know it could work (or not).
Could anyone give me a hint?
Thanks.
Sorry, not idea what you are actually asking, and what it has to do with the thread title.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

gounthar
Posts: 28
Joined: Mon Jul 29, 2013 1:39 pm

Re: GPU memory problem

Thu Oct 04, 2018 10:46 am

I'm asking for some help on how to handle the memory sharing between the GPU and CPU for my use case, which is (supposed to be) a fancy development environment under ArchLinux.
If this ever succeeds, I will use it in a workshop next week at the local university.
Thanks.
2*3B at home for the kids
7*3B+ at work for serious business (gitlab-runner, broadcasting conference, openSTF server...)
Hoping to get a few hats in the following weeks

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27084
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPU memory problem

Thu Oct 04, 2018 11:42 am

gounthar wrote:
Thu Oct 04, 2018 10:46 am
I'm asking for some help on how to handle the memory sharing between the GPU and CPU for my use case, which is (supposed to be) a fancy development environment under ArchLinux.
If this ever succeeds, I will use it in a workshop next week at the local university.
Thanks.
Just use the default I would think.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

luntik2012
Posts: 1
Joined: Mon Oct 01, 2018 1:12 pm

Re: GPU memory problem

Wed Jan 09, 2019 2:15 pm

the same problem on rpi3 b+ and archlinux from http://os.archlinuxarm.org/os/ArchLinux ... est.tar.gz

Code: Select all

[   26.864213] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   26.871275] [drm]                            V3D:  51120kb BOs (48)
[   26.877632] [drm]                     V3D shader:     56kb BOs (14)
[   26.884030] [drm]                           dumb:   8148kb BOs (4)
[   26.890330] [drm]                total purged BO:   8236kb BOs (5)
[   26.896904] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   26.903931] [drm]                            V3D:  51052kb BOs (46)
[   26.910322] [drm]                     V3D shader:     56kb BOs (14)
[   26.916680] [drm]                           dumb:   8148kb BOs (4)
[   26.922969] [drm]                total purged BO:   8236kb BOs (5)
[   26.929682] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   26.936664] [drm]                            V3D:  51052kb BOs (46)
[   26.943072] [drm]                     V3D shader:     56kb BOs (14)
[   26.949460] [drm]                           dumb:   8148kb BOs (4)
[   26.955729] [drm]                total purged BO:   8236kb BOs (5)
[   26.962034] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.
[   26.974822] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   26.981875] [drm]                            V3D:  51052kb BOs (46)
[   26.988232] [drm]                     V3D shader:     56kb BOs (14)
[   26.994645] [drm]                           dumb:   8148kb BOs (4)
[   27.000939] [drm]                total purged BO:   8236kb BOs (5)
[   27.007531] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[   27.014539] [drm]                            V3D:  51052kb BOs (46)
[   27.020920] [drm]                     V3D shader:     56kb BOs (14)
[   27.027278] [drm]                           dumb:   8148kb BOs (4)
[   27.033638] [drm]                total purged BO:   8236kb BOs (5)

Code: Select all

[root@alarm ~]# cat /boot/config.txt 
#gpu_mem=256
dispmanx_offline=1
#dtoverlay=vc4-fkms-v3d
avoid_warnings=2
dtparam=audio=on
disable_overscan=1
dtoverlay=vc4-kms-v3d
cma_lwm=16
cma_hwm=256
cma_offline_start=16
dtparam=spi=on
[root@alarm ~]# cat /boot/cmdline.txt 
root=/dev/mmcblk0p2 rootfstype=ext4 rw rootwait loglevel=0 console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 elevator=noop cma=256M


puzzle-star
Posts: 3
Joined: Mon Feb 17, 2020 6:06 pm

Re: GPU memory problem

Mon Feb 17, 2020 6:56 pm

This is a somehow old topic, but I have spent the last days trying to find a solution for this:
[ 26.929682] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 26.936664] [drm] V3D: 51052kb BOs (46)
[ 26.943072] [drm] V3D shader: 56kb BOs (14)
[ 26.949460] [drm] dumb: 8148kb BOs (4)
[ 26.955729] [drm] total purged BO: 8236kb BOs (5)
[ 26.962034] vc4_v3d 3fc00000.v3d: Failed to allocate memory for tile binning: -12. You may need to enable CMA or give it more memory.

I have not been able to find a real "recent" solution to this on google. The issue here is what "recent" means:

- Some fixes and posts about this are old (2018, old kernel, prior to dynamic CMA removal)
- Recent kernels should fix this ">5.x.x"
- Raspbian is in the middle.... (4.19)

So the solution:

Code: Select all

echo on >/sys/devices/platform/soc/*.v3d/power/control

I hope this saves some time to many people trying to get drm kms / fkms it to work without the rendering engine hanging a few minutes after booting...

The reason (from looking for the error at the kernel source, and "tracing" back):

In this version of the kernel, the tile binning memory buffer is allocated when the device is loaded onto the kernel (good!) but it gets freed when the device goes into "runtime suspended" state. This is different from hibernating or suspending the system: this is the kernel putting specific devices in "runtime suspended" mode when not used for some time to save power.

So when the kernel wakes the device up again, there is a high probability that the driver will not find a new 16M contiguous memory block available in the CMA area for the tile binning memory. Hence the error (and frozen rendering with rebooting being the only solution).

The solution, above, is forcing the drm device to be always "on", disabling automatic "runtime suspend" before it freezes (so at boot).

In newer kernels, the tile binning memory block is allocated only when the first application requires tile binning memory, and freed when the last thread frees it (so the situation becomes worse), but so far I found, as a workaround, to compile a small "daemon" that allocates 1 byte for tile binning, and immediately suspends forever, so the 16M block will never be freed, leaving most of it available for real apps using it. Let's see if still needed when raspbian gets to kernel 5.x.x...

Edit: I have changed part of the device name in the command above by a wildcard '*', as it seems the device name may vary between systems (or maybe pi models).


Pedro
Last edited by puzzle-star on Wed Feb 19, 2020 8:01 pm, edited 2 times in total.

ejolson
Posts: 5810
Joined: Tue Mar 18, 2014 11:47 am

Re: GPU memory problem

Mon Feb 17, 2020 7:34 pm

puzzle-star wrote:
Mon Feb 17, 2020 6:56 pm
This is a somehow old topic, but I have spent the last days
Welcome to the forum!

Thanks for a fantastic analysis of the problem and a work around! I hope the new 5.x kernels behave better.

puzzle-star
Posts: 3
Joined: Mon Feb 17, 2020 6:06 pm

Re: GPU memory problem

Wed Feb 19, 2020 7:50 pm

Just to add to the above solution (or workaround, as you prefer :) ), to make the change permanent, and as it needs to be applied after reboot...

Create a file called /usr/local/sbin/disable-drm-pm:

Code: Select all

#!/bin/bash

[ -n "$1" ] || exit 1

echo "on" > "/sys/$1/power/control"

Make it executable:

Code: Select all

chmod 755 /usr/local/sbin/disable-drm-pm

Create a file called /etc/udev/rules.d/70-persistent-drm.rules:

Code: Select all

SUBSYSTEM=="platform", KERNEL=="*.v3d", ACTION=="add", RUN+="/usr/local/sbin/disable-drm-pm '%p'"

With the above, the change will be applied after reboot.

Edit: I have changed part of the device name in the udev rule above by a wildcard '*', as it seems the device name may vary between systems (or maybe pi models).


Pedro

audetto
Posts: 42
Joined: Fri Feb 28, 2014 8:44 pm

Re: GPU memory problem

Thu Apr 02, 2020 7:53 pm

puzzle-star wrote:
Mon Feb 17, 2020 6:56 pm

The solution, above, is forcing the drm device to be always "on", disabling automatic "runtime suspend" before it freezes (so at boot).

Pedro
What are the side effects of this disabling runtime suspend? Temperature, CPU?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 27084
Joined: Sat Jul 30, 2011 7:41 pm

Re: GPU memory problem

Thu Apr 02, 2020 8:25 pm

audetto wrote:
Thu Apr 02, 2020 7:53 pm
puzzle-star wrote:
Mon Feb 17, 2020 6:56 pm

The solution, above, is forcing the drm device to be always "on", disabling automatic "runtime suspend" before it freezes (so at boot).

Pedro
What are the side effects of this disabling runtime suspend? Temperature, CPU?
Not measured, but I would expect insignificant.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

audetto
Posts: 42
Joined: Fri Feb 28, 2014 8:44 pm

Re: GPU memory problem

Mon Apr 06, 2020 7:16 pm

Will we have this integrated is raspi-config or even better fixed in a future kernel version?

pjft
Posts: 16
Joined: Fri Jan 20, 2017 11:02 pm

Re: GPU memory problem

Sun Apr 12, 2020 3:58 pm

puzzle-star wrote:
Wed Feb 19, 2020 7:50 pm
Just to add to the above solution (or workaround, as you prefer :) ), to make the change permanent, and as it needs to be applied after reboot...

Create a file called /usr/local/sbin/disable-drm-pm:

Code: Select all

#!/bin/bash

[ -n "$1" ] || exit 1

echo "on" > "/sys/$1/power/control"

Make it executable:

Code: Select all

chmod 755 /usr/local/sbin/disable-drm-pm

Create a file called /etc/udev/rules.d/70-persistent-drm.rules:

Code: Select all

SUBSYSTEM=="platform", KERNEL=="*.v3d", ACTION=="add", RUN+="/usr/local/sbin/disable-drm-pm '%p'"

With the above, the change will be applied after reboot.

Edit: I have changed part of the device name in the udev rule above by a wildcard '*', as it seems the device name may vary between systems (or maybe pi models).


Pedro
So, I'm running into a similar CMA issue and this seems to be most promising lead I ran into.

That being said, the issue is that I do not have any *.v3d device on the /sys/devices/platform/soc tree. This is my current tree:

Code: Select all

driver_override       fe101000.cprman/      fe209000.dsi/         ff800000.local_intc/  soc:firmware/         subsystem/
fd5d2200.thermal/     fe104000.rng/         fe215000.aux/         modalias              soc:gpu/              uevent
fe007000.dma/         fe200000.gpio/        fe300000.mmcnr/       of_node/              soc:power/            
fe00b880.mailbox/     fe200000.gpiomem/     fe340000.emmc2/       power/                soc:vcsm/             
fe100000.watchdog/    fe201000.serial/      fe600000.firmwarekms/ soc:audio/            soc:virtgpio/
I'm on a Pi4, Linux rpi4 4.19.97-v7l+, running vc4-fkms-v3d .

My allocation issues did not have the V3D entry such as yours, just repeatedly:

Code: Select all

kernel: [20568.377028] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
kernel: [20568.377034] [drm]                           dumb: 218704kb BOs (28)
Maybe I missed something or any pointers here would help?

I'm trying to increase cma from 256m to 512m, and setting coherent_pool=6M (from a 1M previous setting) to see if it helps - all from other posts and GitHub threads - but would love to get to the bottom of this. Would going straight for

Code: Select all

devices/platform/soc/soc\:gpu/power/control
even make sense to try?

Apologies as I'm kind of flying blind here.

Thanks.

fengggli
Posts: 1
Joined: Sat Apr 25, 2020 2:17 pm

Re: GPU memory problem

Sat Apr 25, 2020 2:21 pm

I can confirm that I have the same issue. Same 4.19.97-v7l+ kernel, with no *.v3d file in /sys/devices/platform/soc.
I want to try 5.0+ kernel but am afraid i will break sth..
pjft wrote:
Sun Apr 12, 2020 3:58 pm
puzzle-star wrote:
Wed Feb 19, 2020 7:50 pm
Just to add to the above solution (or workaround, as you prefer :) ), to make the change permanent, and as it needs to be applied after reboot...

Create a file called /usr/local/sbin/disable-drm-pm:

Code: Select all

#!/bin/bash

[ -n "$1" ] || exit 1

echo "on" > "/sys/$1/power/control"

Make it executable:

Code: Select all

chmod 755 /usr/local/sbin/disable-drm-pm

Create a file called /etc/udev/rules.d/70-persistent-drm.rules:

Code: Select all

SUBSYSTEM=="platform", KERNEL=="*.v3d", ACTION=="add", RUN+="/usr/local/sbin/disable-drm-pm '%p'"

With the above, the change will be applied after reboot.

Edit: I have changed part of the device name in the udev rule above by a wildcard '*', as it seems the device name may vary between systems (or maybe pi models).


Pedro
So, I'm running into a similar CMA issue and this seems to be most promising lead I ran into.

That being said, the issue is that I do not have any *.v3d device on the /sys/devices/platform/soc tree. This is my current tree:

Code: Select all

driver_override       fe101000.cprman/      fe209000.dsi/         ff800000.local_intc/  soc:firmware/         subsystem/
fd5d2200.thermal/     fe104000.rng/         fe215000.aux/         modalias              soc:gpu/              uevent
fe007000.dma/         fe200000.gpio/        fe300000.mmcnr/       of_node/              soc:power/            
fe00b880.mailbox/     fe200000.gpiomem/     fe340000.emmc2/       power/                soc:vcsm/             
fe100000.watchdog/    fe201000.serial/      fe600000.firmwarekms/ soc:audio/            soc:virtgpio/
I'm on a Pi4, Linux rpi4 4.19.97-v7l+, running vc4-fkms-v3d .

My allocation issues did not have the V3D entry such as yours, just repeatedly:

Code: Select all

kernel: [20568.377028] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
kernel: [20568.377034] [drm]                           dumb: 218704kb BOs (28)
Maybe I missed something or any pointers here would help?

I'm trying to increase cma from 256m to 512m, and setting coherent_pool=6M (from a 1M previous setting) to see if it helps - all from other posts and GitHub threads - but would love to get to the bottom of this. Would going straight for

Code: Select all

devices/platform/soc/soc\:gpu/power/control
even make sense to try?

Apologies as I'm kind of flying blind here.

Thanks.

puzzle-star
Posts: 3
Joined: Mon Feb 17, 2020 6:06 pm

Re: GPU memory problem

Sun Apr 26, 2020 7:40 pm

I do not have myself a rPi4 to test, and when I looked at the issue for my rPi, I think I saw that the GPU for the rPi4 is different, so probably also the kernel module...

Could you list the the drm related modules loaded on your kernel, and the exact kernel version you have?

I will look at the corresponding kernel branch, but I do not have much time for this, and not sure I will get somewhere without the same HW and kernel version to test.

pjft
Posts: 16
Joined: Fri Jan 20, 2017 11:02 pm

Re: GPU memory problem

Mon Apr 27, 2020 12:08 am

Thanks for the reply. I appreciate the availability.

I'm happy to oblige, though a brief search didn't turn up a clear way on how to provide the info you're looking for, apologies.

I'll try to dig into it during the week, but if anyone wants to give me a nudge in the right direction I'd be very much thankful.

Thanks.

pjft
Posts: 16
Joined: Fri Jan 20, 2017 11:02 pm

Re: GPU memory problem

Tue Apr 28, 2020 8:34 am

Apologies @puzzle-star , in hindsight I understand that might have been a very naive question.

I ran lsmod, and here are the modules listed:

Code: Select all

Module                  Size  Used by
arc4                   16384  0
ecb                    16384  0
md4                    16384  0
md5                    16384  1
sha512_generic         20480  1
cmac                   16384  1
hmac                   16384  2
nls_utf8               16384  1
cifs                  606208  2
ccm                    20480  0
bnep                   20480  2
hci_uart               40960  1
btbcm                  16384  1 hci_uart
serdev                 20480  1 hci_uart
bluetooth             389120  24 hci_uart,bnep,btbcm
ecdh_generic           28672  1 bluetooth
8021q                  32768  0
garp                   16384  1 8021q
stp                    16384  1 garp
llc                    16384  2 garp,stp
evdev                  24576  2
joydev                 20480  0
brcmfmac              311296  0
vc4                   176128  1
brcmutil               16384  1 brcmfmac
drm_kms_helper        184320  2 vc4
sha256_generic         20480  1
v3d                    73728  0
gpu_sched              28672  1 v3d
snd_soc_core          192512  1 vc4
bcm2835_codec          36864  0
snd_compress           20480  1 snd_soc_core
bcm2835_v4l2           45056  0
v4l2_mem2mem           24576  1 bcm2835_codec
snd_pcm_dmaengine      16384  1 snd_soc_core
bcm2835_mmal_vchiq     32768  2 bcm2835_codec,bcm2835_v4l2
syscopyarea            16384  1 drm_kms_helper
drm                   442368  6 v3d,vc4,gpu_sched,drm_kms_helper
v4l2_common            16384  1 bcm2835_v4l2
videobuf2_dma_contig    20480  1 bcm2835_codec
sysfillrect            16384  1 drm_kms_helper
cfg80211              647168  1 brcmfmac
videobuf2_vmalloc      16384  1 bcm2835_v4l2
sysimgblt              16384  1 drm_kms_helper
snd_bcm2835            24576  1
videobuf2_memops       16384  2 videobuf2_dma_contig,videobuf2_vmalloc
drm_panel_orientation_quirks    16384  1 drm
videobuf2_v4l2         24576  3 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
fb_sys_fops            16384  1 drm_kms_helper
rfkill                 28672  6 bluetooth,cfg80211
videobuf2_common       45056  4 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
snd_pcm               102400  4 vc4,snd_pcm_dmaengine,snd_bcm2835,snd_soc_core
snd_timer              32768  1 snd_pcm
videodev              200704  6 bcm2835_codec,v4l2_common,videobuf2_common,bcm2835_v4l2,v4l2_mem2mem,videobuf2_v4l2
snd                    73728  7 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
raspberrypi_hwmon      16384  0
hwmon                  16384  1 raspberrypi_hwmon
media                  36864  3 bcm2835_codec,videodev,v4l2_mem2mem
vc_sm_cma              36864  1 bcm2835_mmal_vchiq
rpivid_mem             16384  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq
hid_dr                 16384  0
uinput                 20480  0
ip_tables              24576  0
x_tables               32768  1 ip_tables
ipv6                  454656  44

uname -a

Code: Select all

Linux 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux

Let me know if there's any more info I can provide here.

Thanks.

lockcda
Posts: 3
Joined: Fri Apr 24, 2020 3:58 pm

Re: GPU memory problem

Fri May 08, 2020 8:46 am

I have a very similar issue on RPi4 with Genoo on 64 bits.

In my case I can adjust the V3D power control with: /sys/devices/platform/v3dbus/fec00000.v3d/power/control. But it makes no difference setting it to "on" (by default its value is "auto"). I also created the udev rule that was suggested in that thread.

The error I can see on dmesg is:

Code: Select all

[  635.005077] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  635.005094] vc4-drm gpu: [drm]                           dumb: 296324kb BOs (1411)
[  635.008044] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  635.008062] vc4-drm gpu: [drm]                           dumb: 296324kb BOs (1411)
[  635.030878] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
It repeats with many entries and the Kb that tries to allocate is increased in time:

Code: Select all

[  909.482971] vc4-drm gpu: [drm]                           dumb: 687108kb BOs (3913)
[  909.491280] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  909.491294] vc4-drm gpu: [drm]                           dumb: 688772kb BOs (3923)
[  909.492425] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  909.492442] vc4-drm gpu: [drm]                           dumb: 688804kb BOs (3924)
[  909.507743] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  909.507756] vc4-drm gpu: [drm]                           dumb: 690724kb BOs (3935)
[  910.007713] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[  910.007727] vc4-drm gpu: [drm]                           dumb: 690916kb BOs (3937)
It happens as fast as I run Chromium, for example, which is unstable now in my system.

I did many tests by giving more memory to CMA on cmdline.txt with cma=<Mb> and that's the summary of the results:

[*] If I set a value for cma that is bigger than gpu_mem, then the kernel won't boot and I can see many USB related errors.
[*] If I set a value for cma smaller than gpu_mem the system boots but the reported error is reproduced (no matter if I assign 128M or 512M, the error is always shown).

Any help would be appreciated.

Return to “Arch”