22:54 <hexdump0815> i just ran into a case where i had to limit the max number of draws per job further to avoid lima errors: https://github.com/hexdump0815/mesa-etc-build/blob/master/limit-max-draws-per-job.patch

22:54 <hexdump0815> with this tweak it was running fine and stable again

22:57 <hexdump0815> ok - i was just able to trigger the problem again even with a limit of 1000

22:57 <enunes> hexdump0815: yeah its a heuristic, in the MR we applied that if I recall correctly we did note that it was possible to craft some programs that would run into any arbitrary limit anyway

22:58 <hexdump0815> enunes: so no real way around it?

22:58 <enunes> i dont remember what was the condition to hit it

23:05 <anarsoul> hexdump0815: fix it in vcvrack

23:06 <anarsoul> hexdump0815: btw, can you share complete dmesg?

23:06 <anarsoul> the two lines that you mention aren't relevant

23:06 <anarsoul> I'm more interested to see what was the real error

23:14 <hexdump0815> anarsoul: there was nothing more in dmesg - maybe i'll have to raise the debug level?

23:15 <enunes> hexdump0815: really, fix that application :)

23:15 <anarsoul> hexdump0815: try "dmesg | grep lima"

23:15 <hexdump0815> fixing it in vcvrack is close to impossible due to its architecture and i think it is simply desgned with a different class of gpus in mind :) ... i'm happy that it runs at all on those little mali gpus

23:18 <hexdump0815> maybe its also hw related - i have another s905x box which is a tiny bit faster with better mem bw and there it is running fine and stable with default values

23:20 <hexdump0815> could also be that its gpu devfreq related as i saw some trouble related to this on that box as well (but not always related to the mentioned log msgs)

23:22 <hexdump0815> i'll check further during the next days and in case i'll get any consistent report i'll let you know

23:23 <anarsoul> hexdump0815: likely it hits task timeout

23:24 <anarsoul> there's a kernel module parameter for lima, sched_timeout_ms

23:24 <anarsoul> it's 500ms by default, you can increase it to 1s

23:24 <anarsoul> or to 2s

23:25 <hexdump0815> anarsoul: oh sorry - forgot to mention it - yes, it was running into the task timeout and i already had raised it to 1s which i remembered from an earlier debug session with you

23:26 <anarsoul> looks like you need more than 1s

23:26 <anarsoul> alternatively, you can run it with sw renderer :)

23:26 <anarsoul> try LIBGL_ALWAYS_SOFTWARE=1

23:27 <hexdump0815> ok - i'll play around with longer timeouts as well ... may it help to increase the heap size a bit like in the old hack: https://github.com/hexdump0815/mesa-etc-build/blob/master/increase-lima-tile-heap-size.patch

23:28 <anarsoul> it should use dynamic heap size if you're using recent kernel

23:28 <hexdump0815> anarsoul: sw renderer does not work as all cpu is used for the rendering then and not enough left for the audio :)

23:28 <hexdump0815> kernel is 5.15.12

23:30 <enunes> hexdump0815: if you can make the application run in lower resolution, that may help it too

23:31 <anarsoul> hexdump0815: that's recent enough :)

23:33 <hexdump0815> ok - thx a lot