DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory

[suijingfeng]

run glxgears with etnaviv hardware acceleration

and drag mouse to enlarge the window cause following issue

284 frames in 5.0 seconds = 56.796 FPS
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory

Can not create dumb buffer bigger than a specific size (1000x1000 or so). this machine using Kunlun firmware. Using etnaviv and loongson-drm on lemote 3a3000 mother board.

Build Operating System: Linux 4.19.112+ mips64
Current Operating System: Linux localhost.localdomain 4.19.128 #2 SMP PREEMPT Fri Jul 3 00:53:50 CST     2020 mips64
Kernel command line: root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/swap rd.lvm.lv=fedora/root rhg    b loglevel=7 console=ttyS0,115200 LANG=zh_CN.UTF-8 rd_start=0x85000000 rd_size=0x226a541 PMON_VER=20190606113559     EC_VER=adec79d-20190509163413  ieee754=relaxed e1000e.InterruptThrottleRate=4,4,4,4

$ cat /proc/cpuinfo

system type     : generic-loongson-machine
machine         : loongson,generic
processor       : 0
cpu model       : Loongson-3 V0.13  FPU V0.1
model name      : Loongson-3A R3 (Loongson-3A3000) @ 1450MHz
CPU MHz         : 1450.00
BogoMIPS        : 2887.52
wait instruction    : yes
microsecond timers  : yes
tlb_entries     : 1088
extra interrupt vector  : no
hardware watchpoint : yes, count: 0, address/irw mask: []
isa         : mips1 mips2 mips3 mips4 mips5 mips32r1 mips32r2 mips64r1 mips64r2
ASEs implemented    : dsp dsp2 loongson-mmi loongson-cam loongson-ext loongson-ext2
shadow register sets    : 1
kscratch registers  : 6
package         : 0
core            : 0
VCED exceptions     : not available
VCEI exceptions     : not available

but the same kernel and kernel modules driver works on other other machine (say 3a3000 or 3a4000 development/evaluation board) without this issue.

That is to say this issue is machine dependent! don't know if it affect by the kernel boot cmd line.

i am using this DDX driver: https://github.com/ProgramingOnLoongson/xf86-video-loongson7a

[FlyGoat]

That is related to memory layout of the specified machine. As Etnaviv can only accept physical address lower than 0x80000000, while for a typical Loongson Machine, the memory layout could be

0x0000_0000 ~ 0x1000_0000 Low Memory
0x1000_0000 ~ 0x1d00_0000 LS7A APB + Config Registers + Shadow of IOPorts
0x1d00_0000 ~ 0x2000_0000 LS3A Config Register + Memory mapped BIOS flash
0x2000_0000 ~ 0x3000_0000 Free but used as some internal signal trigger so can't be used as RAM
0x3000_0000 ~ 0x4000_0000 Free (Used as a part of high_mem on some machine)
0x4000_0000 ~ 0x8000_0000 PCI MMIO BAR (32-bit non-prefetchable)

Thus generally only poor 256MB (0x0000_0000 ~ 0x1000_0000) will be available for etnaviv. Also, firmware & kernel will occupy some memory here, it will run out of memory easily.

Machines with VUMA will shadow some high memory into low address. But not every machine enabled this feature. I assume the board ran out of memory easily didn't deploy VUMA.

[suijingfeng]

But 256MB is really big enough. 1920x1080x4 = 8M

the scan out, fbcon and cusor buffer using DUMB,

take all of this into count we are far from 256MB and the problem is that you can create multiple small DUMB, but you just can not get a big one at a specific invariable size.

it couldn't be "run out of memory", i think.

[suijingfeng]

[suijingfeng]

Yes, your judgement may be right , free_cma:0, poor gc1000 ...

[10668.957031] Call Trace:
[10668.957031] [<ffffffff80218090>] show_stack+0x40/0x130
[10668.957031] [<ffffffff80f7b0dc>] dump_stack+0xac/0xe0
[10668.957031] [<ffffffff803197cc>] dump_header+0x6c/0x298
[10668.996093] [<ffffffff803187c4>] oom_kill_process+0x124/0x3f0
[10668.996093] [<ffffffff803191d8>] out_of_memory+0x118/0x600
[10669.007812] [<ffffffff80319740>] pagefault_out_of_memory+0x80/0xa0
[10669.007812] [<ffffffff80231e98>] tlb_do_page_fault_1+0x120/0x128
[10669.023437] Mem-Info:

active_anon:62055 inactive_anon:7662 isolated_anon:32 active_file:17500 inactive_file:22109 isolated_file:0 unevictable:2 dirty:10 writeback:0 unstable:0 slab_reclaimable:1062 slab_unreclaimable:1920 mapped:20293 shmem:8398 pagetables:802 bounce:0 free:395714 free_pcp:67 free_cma:0