stikonas_ has quit [Remote host closed the connection]
stikonas has joined #panfrost
stikonas has quit [Remote host closed the connection]
vstehle has quit [Ping timeout: 256 seconds]
<icecream95>
HdkR: Anything using glsl crashes with ubsan
<icecream95>
../src/compiler/glsl/ast_to_hir.cpp:2251:4: runtime error: member access within address 0x0111bef4 which does not point to an object of type 'ast_node'
<HdkR>
ooo, fun
yann has quit [Ping timeout: 240 seconds]
yann has joined #panfrost
<alyssa>
Okay, got connectivity sorted out, so I think I can do proper development now
jernej has quit [Ping timeout: 252 seconds]
nerdboy has quit [Ping timeout: 265 seconds]
jernej has joined #panfrost
davidlt has joined #panfrost
nerdboy has joined #panfrost
vstehle has joined #panfrost
buzzmarshall has quit [Remote host closed the connection]
<tomeu>
Lyude: it could be great if you could see why we have such stability issues on the n2
<tomeu>
basically, the first job after the GPU is powered on often fails with 3 different possible errors, at random
<tomeu>
the kbase used in boards with s922x has some hacks to account for a different reset sequence, but after applying the same to panfrost, we still have that unstability
<tomeu>
otherwise, I guess there's lots of compiler and disassembler work that would be great to do at this stage and that don't depend on hw
chewitt has joined #panfrost
<narmstrong>
I’ll try to find some time to reproduce this on the vim3 (g51) and vim3l (g32) to be sure it’s not specific to the n2
<narmstrong>
tomeu: what do you use to send jobs to panfrost ? Do you have an initial mesa fork with working jobs ?
<tomeu>
narmstrong: yes, but alyssa added tests to igt that reproduce it
<alyssa>
robher: Admitedly I was. uhm. Unintentionally soak testing?
<alyssa>
and by that I mean accidentally hammering it with thousands of jobs raising faults per second, accidentally, um
<robher>
Oh, well don't do that. :)
<alyssa>
thanks
robmur01_ has joined #panfrost
<robher>
opening and closing the fd?
<alyssa>
(Note that doesn't require elevated permissions beyond what opengl needs, and the GPU doesn't come back up after without a reboot. So still a local DoS risk.)
<robher>
My guess would be something related to bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
<alyssa>
Perhaps
<alyssa>
Not sure what kernel I'm on exactly (tom?)
<alyssa>
uh tab complete, tomeu ^^
<robher>
5.6-rc5 which should have everything.
<alyssa>
5.6.0-rc5ccu-00026-g2cef95349b7e-dirty
<robher>
plus 26 commits and dirty, so...
<alyssa>
oh I didn't even notice that was in the log
rtp has joined #panfrost
HdkR has joined #panfrost
robmur01_ has quit [Ping timeout: 256 seconds]
<robher>
That way we can blame users for their kernel modifications and tell them it's their fault. :)
<alyssa>
Makes sense
MistahDarcy has joined #panfrost
<robher>
alyssa: can you disassemble panfrost.ko? And add some WARNs for any of the pointers we deref in panfrost_mmu_unmap()
MistahDarcy has quit [Quit: Leaving]
stikonas has quit [Remote host closed the connection]
buzzmarshall has quit [Remote host closed the connection]