mripard / sunxi-mali

GNU General Public License v2.0
100 stars 54 forks source link

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

Open Jeepgoing opened 5 years ago

Jeepgoing commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Jeepgoing commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

zhang-peter commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

zhang-peter commented 5 years ago

@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 commented 5 years ago

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

sergey-suloev commented 5 years ago

@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 commented 5 years ago

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

sergey-suloev commented 5 years ago

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

zhang-peter commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Jeepgoing commented 5 years ago

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

sergey-suloev commented 5 years ago

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 commented 5 years ago

Maybe you can refer to this: https://github.com/mripard/sunxi-mali/issues/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 commented 5 years ago

@avafinger thanks a lot, I'll try it

sergey-suloev commented 5 years ago

@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 commented 5 years ago

yep, fixed with:

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 commented 5 years ago

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

SardorBS commented 5 years ago

@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."