14:57 <mntirc> i have 2 x86 linux games, that, when run by box86, completely lock up (crash/freeze) the rk3588 using panthor: va11halla and dex

14:58 <mntirc> the games work when using LIBGL_ALWAYS_SOFTWARE=1, so that's currently my only evidence that it is gpu/panthor related

14:58 <mntirc> the same games work on the same setup on an a311d system with mali-g52 (panfrost)

14:59 <mntirc> it's kind of hard to get more in-depth debugging data for this because it's impossible to get anything out of the system in this state

15:01 <cphealy> mntirc: Do you have access to UART to see if the kernel is dumping anything before locking up?

15:02 <mntirc> cphealy: IIRC there was nothing but i can try that again on monday

15:03 <cphealy> Another thing you might want to try is creating an apitrace of the game with the a311d and replay it with the RK3588. If the trace also results in the crash, it would be good to make available for others to use to reproduce the failure without need for the full SW stack to run box86 games.

15:08 <mntirc> cphealy: ah, that's a good idea

15:29 <mntirc> cphealy: this worked! i have an apitrace that can lock up the system

15:30 <mntirc> but: it only locks up when running the 32bit/armhf apitrace, so when running through 32bit/armhf mesa

15:30 <mntirc> so this means that an armhf build of mesa/panthor can lock up the rk3588

15:33 <mntirc> here's the trace http://dump.mntmn.com/box86.trace.zip

15:34 <mntirc> when played back on 64bit apitrace it also outputs a lot of messages like > shader compiler issue 1: MESA_SHADER_VARYING shader: 3 inst, 3.000000 cycles, 0.000000 fma, 0.000000 cvt, 0.000000 sfu, 0.000000 v, 0.000000 t, 3.000000 ls, 8 quadwords, 2 threads, 0 loops, 0:0 spills:fills

15:34 <cphealy> mntirc: Excellent! You should probably create a mesa "issue" and point to this trace with the details about armhf

15:34 <mntirc> cphealy: ok, doing that now

15:54 <mntirc> cphealy: here's the issue https://gitlab.freedesktop.org/mesa/mesa/-/issues/10835

15:56 <cphealy> Nice!