02:52 <HdkR> alyssa: It's also only a tiny amoutn of code. Not much logic happening there

02:52 <HdkR> Only spent about an hour or so getting familiar with the code again

05:31 <tomeu> leinax: that file isn't accessible any more

05:32 <tomeu> leinax: is it BOs, or malloced stuff from within Mesa?

05:39 <tomeu> icecream95: haven't seen any, is that easily reproducible with rtcwake?

08:17 <icecream95> tomeu: It seems less of a "5% of the time it doesn't work" problem and more that it works fine

08:17 <icecream95> for a while, then something trips and suspend doesn't work until I reinsert the panfrost module.

08:18 <icecream95> Maybe just restarting Sway would fix it, but I haven't tried that yet.

08:18 <tomeu> icecream95: can it be reproduced with a script that repeatedly calls rtcwake?

08:19 <icecream95> I don't think it can

08:20 <icecream95> Maybe I should make a script than runs rtcwake for three seconds every five minutes, so I can see what

08:20 <icecream95> I was doing when it breaks...

08:26 <icecream95> Running glmark2-es2 -b refract in the background can trigger it, but I'm not sure if it's the same cause

09:20 <tomeu> refract with rtcwake being repeatedly called?

10:15 <robmur01> tomeu: I'd guess either something gets wedged such that panfrost_job_is_idle() returns a false positive, or system suspend really goes quickly enough that the last job is still running

10:16 <robmur01> we might need to reconsider whether force_suspend() is sufficient

10:25 <tomeu> hmm, yeah

10:25 <tomeu> we should really get panfrost igt running in kernelci...

14:44 <leinax> tomeu: Doesn't look like bo's. I can see that weston-simple-egl slowly leaks. It looks like mesa is mallocing every so often. If I catch the brk syscall in gdb the mallocs are consistently originating from panfrost_scoreboard_queue_job_internal's util_dynarray_append calls.

14:46 <tomeu> oh, cool, will take a look with valgrind

14:47 <tomeu> I suspect that would be slowing things quite a bit

14:49 <leinax> Other common source of mallocs seems to be panfrost_batch_update_bo_access calling rzalloc_size. I'm not sure if either of those are the actual source of the leak.

14:57 <tomeu> cool

15:34 <tomeu> alyssa: this branch runs 1 5th of the gles3 tests in the same time that takes to run the full gles2: https://gitlab.freedesktop.org/tomeu/mesa/commits/panfrost-deqp-gles3

15:35 <tomeu> will push a MR once this one is merged: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295

20:15 <HdkR> https://www.engadget.com/2020/01/06/lenovo-ideapad-duet-chromebook-convertible-tablet/ Nice. Bifrost Chromebook

20:37 <alyssa> tomeu: Nice :)

20:38 <alyssa> HdkR: Yupyup

20:52 <krh> yupyup

22:26 <icecream95> for i in {1..10}; do timeout 3 glmark2-es2 -b refract; done seems to be quite a reliable way of triggering recursive faults.

22:26 <icecream95> i.e. you will get a kernel panic or hang soon

22:54 <leinax> This is probably way more useful than what I posted before. weston-simple-egl massif output after several hours: https://pastebin.com/kQz9UBcn

23:33 <m][sko> Nice work with panfrost. I did some runs on MALI T620(Odroid XU4) and there are some artefacts. for example pure weston and glmark2. Are there any change that we see some "love" for T620 :)

23:36 <m][sko> I am really happy with state of panfrost on ubuntu 19.10 with gnome wayland.