Qt5: Unable to set double buffer mode! (Invalid argument); glmark2-es2-fbdev test error:0x3003

[Jeepgoing]

Hi, all:
I have met an error as title described, my environment as below:

OrangePi PC2

kernel: https://github.com/megous/linux

use fbdev mode

I have changed CONFIG_DRM_FBDEV_OVERALLOC from 100 to 200, but it's invalid.

[Jeepgoing]

I don't use qt tests, and try to use glmark2-es2-fbdev, still error as below:

Error: eglInitialize() failed with error: 0x3003
Error: eglInitialize() failed with error: 0x3003
Error: main: Could not initialize canvas

Environment:

Linux kernel: https://github.com/megous/linux.git branch: orange-pi-4.20
Mali linux driver: https://github.com/mripard/sunxi-mali directory: r6p2
Mali blob: https://github.com/bootlin/mali-blobs.git fbdev
Mali fbdev test: https://github.com/avafinger/mali-fbdev-stress-test-tools.git

anybody help me, thanks.

[zhang-peter]

@Jeepgoing The same issue with you, My board is orangepi one, H3.

[Jeepgoing]

I have do lots of tests, including follow @noblock 's introduce:
https://forum.armbian.com/topic/4467-orange-pi-pc2-h5-mali-blob/, but i can't build r5p0 mali driver, errors:

No series file found Error applying patch

noblock's branch: https://github.com/noblock/sunxi-mali.git

[zhang-peter]

@Jeepgoing yeah, my fellow, I know little about mali driver but I can list my environment.
I build an sd image with buildroot 2018.11.
Linux kernel: https://github.com/megous/linux.git branch: orange-pi-4.20

when I set drm_kms_helper.drm_fbdev_overalloc=200 in boot.cmd the qt application just output:

Qt5: Unable to set double buffer mode! (Invalid argument)

then the whole operate system crash.

[Jeepgoing]

@zhang-peter ,what are you going to do next? I want to try lima, which has not released.
https://github.com/yuq/mesa-lima.git

[zhang-peter]

@Jeepgoing I don't have enough time to search sunxi-mali, so I can use Qt 2D Render for now. And I will give a try to mesa-lima.

[sergey-suloev]

@Jeepgoing it seems to me that a similar issue was discussed intensively some time ago, so look into closed issues

[zhang-peter]

@sergey-suloev I have read the issue #15 that you opened and checked all environment:

cat /sys/class/graphics/fb0/virtual_size
1366,1536

cat /sys/class/graphics/fb0/modes
U:1366x768p-0

dmesg | grep CMA
Reserved memory: created CMA memory pool at 0x000000004a000000, size 128 MiB

mali: loading out-of-tree module taints kernel.
Allwinner sunXi mali glue initialized
Mali:
Found Mali GPU Mali-400 MP r1p1
Mali:
2+0 PP cores initialized
Mali:
Mali device driver loaded

but the whole system just crash after my qt5 app says:

QML debugging is enabled. Only use this in a safe environment.
Unable to set double buffer mode! (Invalid argument)
QFbVtHandler: socketpair() failed (Function not implemented)
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM

Do you have any suggestion? Thanks!

[sergey-suloev]

@zhang-peter
In my opinion the Qt5 crash wouldn't mean that there was something wrong with Mali kernel module. Did you try the sample application (showing a triangle)?
What userspace components (blobs) are you using, by the way ? What kind of Qt5 integration (eglfs_kms ?) are you using ?
I have noticed that you are using a custom kernel. Why don't you try mainline, let's say 4.19.12, it is quite stable now.
As you can see there might be a goddamn lot of reasons why it is not working for you.

[Jeepgoing]

@sergey-suloev
Hi, actually, i also have tested mainline kernel 4.19.0, it is the same error

Qt5: Unable to set double buffer mode! (Invalid argument)

Could you tell me which target board your use? my target board is Orangepi PC2, if you can show your test environment to github will be best. and i will learn more form it.

[sergey-suloev]

@Jeepgoing
hi if you want to get help I'd recommend you publish your build framework (scripts) on github (or any other) so that we can see what's going on there.

[zhang-peter]

@sergey-suloev, Actually I use blob from  https://github.com/bootlin/mali-blobs.git,
and I try a test from your repo an hour ago, https://github.com/sergey-suloev/sunxi-mali/blob/master/examples/mali_test/test.c. unfortunately, it crashed again!

./mali_test
EGL Version: "1.4 Linux-r6p2-01rel0"
EGL Vendor: "ARM" EGL Extensions:

I will try a clean mainline kernel. thanks a lot!

[sergey-suloev]

@zhang-peter
what kind of crash is this , kernel level (oops) or user space ? what is your dmesg saying ?

[zhang-peter]

@sergey-suloev, it's kernel level, uart console stop respond to me. all led light turn off and I can't dmesg any more. (╥_╥)

[zhang-peter]

I guess it's an issue from kernel or toolschain(linaro)，so I will try another kernel or compiler. @sergey-suloev

[sergey-suloev]

@zhang-peter
just to be 100% sure,
could you measure voltages +5V and +3.3V on corresponding GPIO pins
1)just after reboot
2) after the crash

[zhang-peter]

@sergey-suloev do you mean power supply pins? I wonder a crash could affect their voltage. but i will try tomorrow.

[sergey-suloev]

@zhang-peter
you need to be 100% sure that your power supply is not failing before you start resolving software issues

[zhang-peter]

@sergey-suloev now I am sure the power supply is okay. And new message come out:

EGL Version: "1.4 Linux-r6p2-01rel0"
EGL Vendor: "ARM"
EGL Extensions: "EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_ren"
Surface size: 480x320
GL Vendor: "ARM"
GL RUnable to handle kernel paging request at virtual address 637470c7
enderer: "Mali-400 MP"
GL Version: "OpenGL ES 2.0"
GL Extensiopgd = 21fff71f
ns: "GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_comprUnable to handle kernel paging request at virtual address 014f3bb8
[637470c7] *pgd=00000000
pgd = ffd19614
essed_ETC1_RGB8_texture GL_EXT_compressed_ETC1_RGB8_sub_texture Unable to handle kernel NULL pointer dereference at virtual address 0000045a
[014f3bb8] *pgd=80000040004003, *pmd=00000000
Unable to handle kernel NULL pointer dereference at virtual address 00000025
Unable to handle kernel NULL pointer dereference at virtual address 00000258
Unable to handle kernel NULL pointer dereference at virtual address 00000025
Unable to handle kernel paging request at virtual address 33e59254
Unable to handle kernel NULL pointer dereference at virtual address 00000025
GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_AUnable to handle kernel paging request at virtual

[Jeepgoing]

@zhang-peter @sergey-suloev

./mali_test
Error: eglInitialise failed!

dmesg | grep -i mali
[ 4.597330] mali: loading out-of-tree module taints kernel.
[ 4.619094] Allwinner sunXi mali glue initialized
[4.621619] Mali:
[4.621623] Found Mali GPU Mali-450 MP r0p0
[4.624190] Mali:
[4.729121] Mali:
[4.729125] Mali device driver loaded

[sergey-suloev]

@zhang-peter @Jeepgoing
I tried your scenario and got the same issue. So we're all in the same boat.

OrangePi PC
Kernel 4.19.12
Qt 5.11
Mali r6p2
Mali blobs https://github.com/bootlin/mali-blobs/tree/master/r6p2/arm

@mripard This is definitely meaning that either Mali driver or blob isn't working anymore. I haven't tested it for a long time, and there have been changes to the driver source code and the kernel source too. My last successful experience was with v4.17.

I can't get complete oops information yet but I can see a line in console before my device crashes:

Internal error: 0ops - undefined instruction: 0 [#1] SMP ARM

[zhang-peter]

@sergey-suloev I try the clean mainline kernel today.
Kernel 4.19.9 can't load mali, kernel 4.20 can load it but turn out the same crashes.

[sergey-suloev]

@zhang-peter
That is not going to help IMHO.
Something makes me think that the blob we are using isn't actually compatible with our hardware, i.e. this isn't our fault and there is nothing we can do about it.
Try to find an alternative blob, maybe.
Have you tried sun4i DRM + wayland blob, by the way ? This will require eglfs_kms integration instead of eglfs_mali in Qt5.

[sergey-suloev]

I have tested sun4i DRM + wayland blob and it seems to work fine. But I can't say for sure that hardware acceleration is utilized in this configuration.

lsmod shows that mali module is used:

root@orangepipc-stretch:~# lsmod
Module Size Used by
mali 208896 1

here is my qt5 log https://pastebin.com/2C8tiMaV

[sergey-suloev]

I recompiled the driver in debug mode and I can finally see the driver activity, so yes, it seems like hardware acceleration is involved when using the Wayland blob.

[sergey-suloev]

@mripard could you verify one more time, please, whether you provide the correct fbdev blob for armhf ?

[Jeepgoing]

@sergey-suloev
Thank you for your help, I haven't try wayland mode, and I will give a try today.

[sergey-suloev]

I have tested aarch64 Mali fbdev blob, same story.

NanoPi A64
Kernel 4.19.12
Qt 5.11
Mali r6p2
Mali blobs https://github.com/bootlin/mali-blobs/tree/master/r6p2/arm64

qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_emu", "eglfs_mali")
qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_mali", "eglfs_emu")
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_mali"
qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_mali"
Unable to set double buffer mode! (Invalid argument)

Then kernel oops and the device hangup.

[avafinger]

Maybe you can refer to this: #54
I use r8p1 on H2+ that should work on H3 just fine. r8p1 works on A64 with kernel 4.4.
There is a patch attached that can help you.

[sergey-suloev]

@avafinger thanks a lot, I'll try it

[sergey-suloev]

@avafinger
I think our problem has nothing to do with "reserved-memory", because on my orangepipc (32bit arm) I have "reserved-memory" and on my nanopi-a64 (64bit arm) I don't. On both platforms the issue exists.

Did you finally resolve your issue 54 and how ?

[avafinger]

yep, fixed with:

• back-ported DRM_FBDEV_LEAK_PHYS_SMEM from 4.20 to 4.19 (patch is attached on the thread)
• set drm_leak_fbdev_smem on compile time (for some reason, passing in command line did not help)
• use latest r8p1 (h2+ and A64)

reserved-memory does not make any difference (with or without it) and change 100 to 200 for double buffering.

unfortunately, i am not a qt5 fan. I would like to work with straight C so setting up a qt5 environment does not appeal to me, but i can't find a c framework as complete as qt5.

[sergey-suloev]

@avafinger I followed your recommendations but this unfortunately hasn't fixed our issue.

[SardorBS]

@mripard, Hi, I'm using buildroot for orangePi-pc-plus (h3). Linux kernel 5.2.
i set CONFIG_DRM_FBDEV_OVERALLOC=200 to achieve double buffer, cma=128;
Qt5 says:
Unable to set double buffer mode! (Invalid argument)
segmentaion fault.
buildroot:
sunxi-mali-mainline-driver-edd3cf4ae7ea5ec573a0eccfbbeb985244499a00/r6p2 /home/111/buildroot-2019.08/output/build/sunxi-mali-mainline-driver-edd3cf4ae7ea5ec573a0eccfbbeb985244499a00

Applying 0001-makefile-Add-install-target-and-build-the-module-by-.patch using series:
patching file src/devicedrv/mali/Makefile
Hunk #1 succeeded at 193 (offset 16 lines).

Applying 0002-mali-Support-building-against-4.6.patch using series:
patching file src/devicedrv/mali/linux/mali_memory_swap_alloc.c

Applying 0003-mali-Support-building-against-4.8.patch using series:
patching file src/devicedrv/mali/linux/mali_memory_os_alloc.c
Hunk #2 succeeded at 515 (offset 7 lines).
Hunk #3 succeeded at 558 (offset 7 lines).
Hunk #4 succeeded at 618 (offset 7 lines).
Hunk #5 succeeded at 772 (offset 7 lines).

Applying 0004-mali-Print-the-mali-version-at-probe.patch using series:
patching file src/devicedrv/mali/common/mali_kernel_core.c

Applying 0005-mali-Add-sunxi-platform.patch using series:
patching file src/devicedrv/mali/platform/sunxi/sunxi.c

Applying r6p2/0006-mali-Allow-devfreq-to-run-without-power-models.patch using series:
patching file src/devicedrv/mali/linux/mali_devfreq.c

Applying 0007-mali-support-building-against-4.10.patch using series:
patching file src/devicedrv/mali/linux/mali_memory.c

Applying 0008-mali-support-building-against-4.11.patch using series:
patching file src/devicedrv/mali/linux/mali_memory.c

Applying r6p2/0009-mali-Fix-user-memory-domain-fault.patch using series:
patching file src/devicedrv/mali/common/mali_gp_job.c

Applying 0010-mali-support-building-against-4.12.patch using series:
patching file src/devicedrv/mali/linux/mali_osk_specific.h

Applying r6p2/0011-mali-support-building-against-4.13.patch using series:
patching file src/devicedrv/mali/linux/mali_kernel_linux.h

Applying 0012-mali-support-building-against-4.14.patch using series:
patching file src/devicedrv/mali/linux/mali_memory_swap_alloc.c

Applying r6p2/0013-mali-support-building-against-4.15.patch using series:
patching file src/devicedrv/mali/common/mali_control_timer.c
patching file src/devicedrv/mali/common/mali_group.c
patching file src/devicedrv/mali/common/mali_osk_types.h
patching file src/devicedrv/mali/linux/mali_memory_os_alloc.c
patching file src/devicedrv/mali/linux/mali_osk_timers.c

Applying r6p2/0014-mali-Make-devfreq-optional.patch using series:
patching file src/devicedrv/mali/linux/mali_devfreq.c

Applying 0015-Enable-parallel-building-passing-variable-to-Makefile.patch using series:
patching file src/devicedrv/mali/Makefile

Applying r6p2/0016-mali-support-building-against-4.16.patch using series:
patching file src/devicedrv/mali/linux/mali_memory_secure.c

Applying 0018-mali-support-building-against-4.20.patch using series:
patching file src/devicedrv/mali/linux/mali_kernel_linux.c
Hunk #1 succeeded at 1125 (offset 193 lines).
patching file src/devicedrv/mali/linux/mali_kernel_linux.h
Hunk #1 succeeded at 16 with fuzz 1.
Hunk #2 succeeded at 34 (offset 5 lines).
patching file src/devicedrv/mali/linux/mali_osk_time.c

Applying 0019-mali-support-building-against-5.0.patch using series:
patching file src/devicedrv/mali/linux/mali_kernel_linux.h
Hunk #1 succeeded at 43 (offset 5 lines).
patching file src/devicedrv/mali/linux/mali_ukk_mem.c

Applying 0020-mali-support-building-against-4.17.patch using series:
patching file src/devicedrv/mali/linux/mali_memory.c
/home/111/buildroot-2019.08/output/build/sunxi-mali-mainline-driver-edd3cf4ae7ea5ec573a0eccfbbeb985244499a00
make[1]: Entering directory '/home/111/buildroot-2019.08/output/build/sunxi-mali-mainline-driver-edd3cf4ae7ea5ec573a0eccfbbeb985244499a00/r6p2/src/devicedrv/mali'
Makefile:173: "You want to support DEVFREQ but kernel didn't support DEVFREQ."