17:05 <gamiee> Hello, does anyone encountered Segfault inside "sun4i-drm_dri.so"? I have latest mesa and Xorg server, but still, I can't figure out :( Any ideas where can be problem? Thanks (full info: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4861 )

17:07 <enunes> gamiee: hi, no I have never seen that one

17:08 <gamiee> enunes: me neither (mostly, lima was working out of the box (on Debian or Ubuntu)). But now I'm compiling mesa and xorg server from scratch via buildroot, and somehow it don't want to work :/

17:10 <jernej> gamiee: it's always good idea to test with unpatched kernel

17:11 <enunes> gamiee: I would guess it won't be a lima issue in the end since it is inside sun4i-drm_dri.so and not even lima

17:11 <enunes> but segfault is not great

17:11 <enunes> I think it would be at least more helpful if you can rebuild with debug symbols enabled so the backtrace is not that limited

17:12 <gamiee> jernej: hi, well, I can try this, but same kernel (from megous) is used in Armbian, and it works just fine, but I might try that.

17:12 <enunes> also I would suggest to enable kmscube and try that too before Xorg

17:13 <gamiee> enunes: kmscube works just fine

17:14 <enunes> ah, I see it is reported there too

17:14 <gamiee> and yeah, I kinda didn't realized that it's not lima problem, but isn't sun4i-drm_dri built by mesa (so I placed the issue to mesa repo)

17:14 <enunes> it is build by mesa

17:15 <gamiee> about full symbols, I wonder how I will force Buildroot to do that, but I'm going to try that right now

17:16 <enunes> there is a global option to disable symbol strip and another to build with optimize for debugging

17:18 <enunes> I used it with Buildroot for a long time as my first lima development system, not much anymore these days

17:18 <gamiee> enunes: thanks, I'm recompiling mesa3d now with debug symbols, hopefully I will get more information

17:23 <gamiee> btw I just noticed, I see there "lima_dri.so", what is difference between sun4i dri ?

17:29 <enunes> sun4i gets loaded because that is what matches your display driver, when you use the display and it needs to render something, the rendering calls are passed to lima

17:34 <gamiee> oh, makes sense!

17:35 <gamiee> Well, now I tried it with mesa3d with symbols, but now I'm getting Abort instead segmentation fault (maybe because I didn't recompiled the whole os?)

17:35 <gamiee> https://paste.ubuntu.com/p/tcp69bwRfc/

17:37 <anarsoul> gamiee: you hit it because the issue is caught earlier with assert()

17:38 <anarsoul> I wonder if BO allocation fails

17:38 <anarsoul> do you have enough CMA reserved?

17:39 <enunes> dmesg in the issue says cma: Reserved 128 MiB at 0x75c00000 so i think so

17:40 <enunes> I think it is worth checking with an upstream kernel, that kernel seems to be heavily patched on sun4i-drm

17:40 <anarsoul> gamiee: what's your display resolution?

17:40 <gamiee> anarsoul: ahh, the assert makes sense. About CMA, I wasn't changing it, so it should be on default value. (as enunes said, it probably is)

17:41 <gamiee> Resolution is 1440x900

17:41 <anarsoul> gamiee: can you get a backtrace with debug symbols?

17:43 <gamiee> anarsoul: backtrace of assert I posted upper is set on "optimize for debugging" level, but I'm going to try something. w8

17:44 <anarsoul> try setting breakpoint on ../src/gallium/frontends/dri/dri2.c:563

17:44 <anarsoul> i.e. before staring your app do "break ../src/gallium/frontends/dri/dri2.c:563"

17:45 <anarsoul> then "r" (for run)

17:45 <anarsoul> it should stop on this line and you can do 'bt'

17:48 <anarsoul> it asserts because resource_from_handle() returned NULL

17:49 <anarsoul> i.e. lima_resource_from_handle()

17:50 <anarsoul> I bet it fails early with debug_error("import buffer offset not properly aligned\n");

17:50 <gamiee> anarsoul: https://paste.ubuntu.com/p/hz3SnTRTQj/

17:51 <anarsoul> please try again, this time set breakpoint on "lima_resource_from_handle" (i.e. break lima_resource_from_handle)

17:51 <anarsoul> when you get there

17:51 <anarsoul> do "print handle->offset"

17:52 <gamiee> $1 = 0

17:54 <anarsoul> do "next" until it fails and share the output

17:56 <gamiee> anarsoul: https://paste.ubuntu.com/p/dZK2dCvHG7/

17:58 <anarsoul> so lima_bo_import() fails

17:58 <anarsoul> gamiee: set breakpoint on lima_bo_import

17:59 <anarsoul> and try again, i.e. restart the app and when it hits breakpoint do "n" until it fails, then share the output

18:05 <gamiee> ok sec.

18:06 <gamiee> https://paste.ubuntu.com/p/vH5rQhCqXF/

18:07 <anarsoul> so drmIoctl(screen->fd, DRM_IOCTL_GEM_OPEN, &req)) failed

18:08 <anarsoul> that's display driver FD

18:08 <anarsoul> so enunes is right - try with unpatched sun4i driver

18:14 <gamiee> anarsoul: okay, I'm going to try mainline kernel without patches, w8

18:16 <anarsoul> you can also try pinging megi :)

18:22 <gamiee> anarsoul: also good idea, but well, let's try mainline kernel. Also, I have verified that megi's kernel works good, but for version 5.10 (armbian uses it)

18:23 <gamiee> So maybe between 5.10 and 5.12 something happened

18:42 <gamiee> anarsoul: looks like even on mainline 5.12 (without patches) it does the same, but to be sure, I'm going to rebuild everything (since buildroot likes to keep old things)

18:43 <anarsoul> gamiee: could be some change in sun4i or in generic gem code

18:43 <anarsoul> it doesn't look like a userspace issue anyway

19:24 <gamiee> anarsoul: confirmed, it doesn't work on 5.12 . I will try 5.10 tomorrow. So far thank you for help guys :)