Vivante GPU Kernel Crash

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Vivante GPU Kernel Crash

966 Views
matttucker
Contributor I

Problem Description

We are rendering maps (e.g. roads, paths, lakes, buildings, etc.) using OpenVG on a i.MX Sololite.  Occasionally our application locks up at an openVG command accessing the GPU (e.g. vgDrawGlyph) and just hangs and goes into an uninterruptible sleep.  In dmesg we see that the GPU kernel has crashed (see logs below). In our application it is unclear what is causing this. What can be done to debug and solve this issue? Will a newer version of the GPU driver help in this issue? Or is there a problem with our application?

Any help would be greatly appreciated!

What we have done so far

We have checked for openvg errors throughout our code with vgGetError() and have not found anything unusual Also we have confirmed that all created vg paths and paints are destroyed correctly. The crash is not always repeatable, but  to produce the crash we typically run a demo that simulates changes of position along a route. This can cause the app to crash fairly repeatably in a few minutes especially if we draw more road names. If we remove the drawing of road names it can take longer for the crash to occur. We have also increased the GPU memory to 64MB but that did not help.

Versions

i.MX 6SoloLite

Galcore version 5.0.11.41671

Linux 4.1.46+g149ee0553478 #4 SMP PREEMPT Wed Jan 23 18:49:53 UTC 2019 armv7l GNU/Linux

Logs

[Jan23 20:01] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[ +0.000022] pgd = c0004000
[ +0.000013] [0000000c] *pgd=00000000
[ +0.000024] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ +0.004120] Modules linked in: usb_f_ecm u_ether usb_f_mass_storage usb_f_acm u_serial libcomposite galcore(O) evbug
[ +0.009408] CPU: 0 PID: 111 Comm: Vivante Kernel Tainted: G O 4.1.46+g149ee0553478 #4
[ +0.007748] Hardware name: Freescale i.MX6 SoloLite (Device Tree)
[ +0.004801] task: c64eed00 ti: c7a1e000 task.ti: c7a1e000
[ +0.004260] PC is at _EventHandler_COMMAND_0+0x50/0x114 [galcore]
[ +0.004919] LR is at gckOS_AcquireMutex+0x68/0x78 [galcore]
[ +0.004283] pc : [<bf029728>] lr : [<bf007f84>] psr: 600f0113
sp : c7a1ff00 ip : c7a1fee8 fp : c7a1ff24
[ +0.008878] r10: 00000000 r9 : 00000000 r8 : c79d8e10
[ +0.003927] r7 : c79d8000 r6 : c67a0980 r5 : 00000000 r4 : 00000008
[ +0.005231] r3 : c64eed00 r2 : 00000000 r1 : c79dc3c0 r0 : 00000000
[ +0.005234] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ +0.006011] Control: 10c53c7d Table: 869f804a DAC: 00000015
[ +0.004452] Process Vivante Kernel (pid: 111, stack limit = 0xc7a1e210)
[ +0.005407] Stack: (0xc7a1ff00 to 0xc7a20000)
[ +0.003071] ff00: 00000001 c621f840 c621f800 c621fa0c 00000000 00000000 c7a1ff44 c7a1ff28
[ +0.006886] ff20: bf02b4f8 bf0296e4 c621f800 c67a0ac0 c621f800 bf02b510 c7a1ff5c c7a1ff48
[ +0.006888] ff40: bf02b53c bf02b4a4 00000000 c67a0ac0 c7a1ffac c7a1ff60 c004e4f8 bf02b51c
[ +0.006884] ff60: c0530534 00000000 c7a1ff94 c621f800 00000000 00000000 c7a1ff78 c7a1ff78
[ +0.006887] ff80: 00000000 00000000 c7a1ff88 c7a1ff88 c67a0ac0 c004e3fc 00000000 00000000
[ +0.006882] ffa0: 00000000 c7a1ffb0 c000fe68 c004e408 00000000 00000000 00000000 00000000
[ +0.006880] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ +0.006884] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 4b18c02f d01a055a
[ +0.007127] [<bf029728>] (_EventHandler_COMMAND_0 [galcore]) from [<bf02b4f8>] (_ProcessInterrupt+0x60/0x78 [galcore])
[ +0.009620] [<bf02b4f8>] (_ProcessInterrupt [galcore]) from [<bf02b53c>] (_MainInterruptHandler+0x2c/0x58 [galcore])
[ +0.009353] [<bf02b53c>] (_MainInterruptHandler [galcore]) from [<c004e4f8>] (kthread+0xfc/0x104)
[ +0.007601] [<c004e4f8>] (kthread) from [<c000fe68>] (ret_from_fork+0x14/0x2c)
[ +0.005934] Code: ea000002 e2555001 e2844008 0a00000f (e5943004)
[ +0.385684] ---[ end trace 64616bb3edcb6ce4 ]---

./gpuinfo.sh mapengine 

---- Running < gpuinfo.sh > test ----
GPU Info
gpu : 1
model : 320
revision : 5007

gpu : 2
model : 355
revision : 1215

VIDEO MEMORY:
gcvPOOL_SYSTEM:
Free : 60022972 B
Used : 7085892 B
Total : 67108864 B
gcvPOOL_CONTIGUOUS:
Used : 0 B
gcvPOOL_VIRTUAL:
Used : 0 B

NON PAGED MEMORY:
Used : 0 B
Paged memory Info
low: 303104 bytes
high: 0 bytes
CMA memory info
cma: 0 bytes
VidMem Usage (Process 435):
Counter: vidMem (for each surface type)
All Index Vertex Texture RT Depth Bitmap TS Image Mask Scissor HZDepth
Current 7085892 0 0 0 0 0 4610944 0 0 0 12800 0
Maximum 7098692 0 0 0 0 0 4610944 0 0 0 25600 0
Total 9172292 0 0 0 0 0 4610944 0 0 0 2099200 0
Counter: vidMem (for each pool)
All 1 2 3 4 5 6 7 8 9
Current 7085892 0 0 0 0 0 7085892 0 0 0
Maximum 7098692 0 0 0 0 0 7098692 0 0 0
Total 9172292 0 0 0 0 0 9172292 0 0 0
Counter: nonPaged
All
Current 0
Maximum 0
Total 0
Counter: contiguous
All
Current 0
Maximum 0
Total 0
Counter: mapUserMemory
All
Current 0
Maximum 0
Total 0
Counter: mapMemory
All
Current 67108864
Maximum 67108864
Total 67108864
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Idle percentage:0.000.000.000.000.000.00%
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

---- Test < gpuinfo.sh > ended ----

0 Kudos
1 Reply

722 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hi Matt,

A VGImage used as a glyph, is still an image, and works exactly the same way as a vgDrawImage(). [A VGFont just takes care of the placement details for you - the rendering is done internally basically just the same as if calling vgDrawPath() and vgDrawImage() with a different transformation matrix]. If you want transparency, I suggest you edit the image and set the alpha channel to 0 for the bits of image you do not wish to display (make sure to save as RGBA - not just plain RGB).

Alternatively, you could create a path representation of the desired letters, and set the glyph to a VGPath (which, upon rendering, would then behave like a vgDrawPath() call).

Regards

0 Kudos