01:34 <davidebeatrici[m]> In order to boot the kernel I add to pass `efi=novamap` to it.

01:34 <davidebeatrici[m]> s/add/had/

01:38 <davidebeatrici[m]> However, it reboots on `Reached target Basic System` when I pass `pd_ignore_unused clk_ignore_unused`. If I omit them it reboots before that, on a black screen.

02:42 <bamse> steev: i took the one you pointed me to ;)

02:43 <bamse> steev: anyway, i don't think it matters...we can work with lenovo to get it updated as needed

02:43 <steev> if needed, like rob said, it just kicks it out of secure mode, so i think any of them would be fine

02:43 <bamse> yeah, interesting to see that they updated it :)

02:47 <davidebeatrici[m]> Could the issue I'm encountering be due to the DTB not being for the specific device (PiPO W12)? If yes, how can I write one?

02:55 <steev> davidebeatrici[m]: you definitely need those 3 options

02:56 <davidebeatrici[m]> You forgot the first one when guiding me yesterday :(

02:56 <steev> you're using mainline or my tree?

02:57 <davidebeatrici[m]> Mainline right now.

02:57 <steev> my tree *should* have a patch so the efi=novamap isn't required

02:57 <steev> shawn wrote it long ago

02:57 <davidebeatrici[m]> Oh, I see.

02:58 <robclark> bamse, steev: if you are that curious, we could kinda disasm it to see what changed.. the zap fw is basically sqe fw w/ some embedded cmdstream plus shaders.. the figuring out what parts are embedded cmdstream/shaders isn't completely automatic yet but doable with some work.. but likely the differences aren't going to be anything that matters without linux supporting secure contexts

03:00 <bamse> robclark: i'm always curious...but there's a few other things that i'm more curious about ;)

03:00 <bamse> robclark: like figuring out how to power up the gpu...

03:00 <steev> i'm curious why mdp breaks when i enable gpu

03:01 <bamse> but first, i got DP working on the CRD today, so need to clean the phy pieces up now

03:01 <bamse> should work on the x13s as well, but haven't tested it yet

03:01 <robclark> yeah, fair.. keep backup copies in case sometime later it bubbles up to top of curiosity pile

03:02 <bamse> :)

03:02 <steev> robclark: should be easy enough, windows keeps at least 2 copies around (3 in the case of the adsp)

03:15 <steev> hm, now i can't find the patch

03:16 <steev> maybe it's something to grub that debian applies...

03:18 <steev> i don't remember, but now i'm not seeing it in my kernel

12:48 <leezu> robclark: the freedreno mesa issue persists after my patch to disable DMABUF_SURFACE_EXPORT in firefox for qualcomm devices. Firefox devs think "it should be pretty obvious to mesa devs when looking at lookup_bo() that they missed some checks somewhere - unless it turns out to be some threading issue (can happen with DMABUF_SURFACE_EXPORT). But as the error happens without

12:48 <leezu> that and IIUC is pretty consistent, that's unlikely." What do you think?

12:53 <leezu> It's easy to repro by navigating to drive.google.com and opening a new tabular sheet document. I linked the nightly build in the issue. It would be great if you can try if you can also repro this.

13:34 <robclark> leezu: I suspect something is scribbling over memory, which is why I suggested valgrind or asan.. if there was a problem with hashtable lookups I doubt it would have gone unnoticed for as many years as that code has existed.. but I can try gsheets later today

14:02 <leezu> I found an easier way to reproduce than opening gsheets is simply navigating to https://registry.khronos.org/webgl/sdk/tests/conformance/attribs/gl-bindAttribLocation-nonexistent-attribute.html?webglVersion=2&quiet=0&quick=1

14:03 <leezu> robclark: Let me take a look at valgrind and asan. My expectation is that at least valgrind will be very slow, but given there's an easy reproducer with the khronos site, it may work

14:18 <robclark> yeah, valgrind is slow.. asan isn't so bad but you need to rebuild mesa w/ llvm and asan enabled

14:20 <robclark> btw, what mesa version?

14:50 <robclark> oh, hmm, ffox isn't so easy to test because of that whole pci issue

15:45 <leezu> Does the build linked in the issue not work for you?

15:48 <leezu> I was on mesa 22.1.3. In the meantime 22.2.0~rc1 was packaged in debian, so can try that too

15:50 <steev> you can also build it from git and use meson devenv

16:29 <robclark> leezu: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17888

16:54 <leezu> robclark: Nice! It helps, but produces this new backtrace:

16:56 <leezu> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17888#note_1496966

16:57 <leezu> Well, not sure if it actually helps. The backtrace still looks the same

17:02 <robclark> are you sure you are using the mesa build you think you are? That is the thing fixed by the MR

17:12 <leezu> It seems I'm missing libEGL_mesa.so and the system library is still used. Is this just an alias of libEGL.so obtained by building mesa?

17:16 <leezu> Also there's this meson warning: WARNING: Library target 'EGL' has 'name_prefix' set. Compilers may not find it from its '-lEGL' linker flag in the 'egl.pc' pkg-config file.

17:16 <leezu> WARNING: Library target 'EGL' has 'name_prefix' set. Compilers may not find it from its '-lEGL' linker flag in the 'egl-uninstalled.pc' pkg-config file.

17:21 <robclark> I think this the _mesa.so versions are intended to be loaded by libglvnd

17:22 <leezu> I observe the following difference in the backtrace without and with the modified LD_LIBRARY_PATH:

17:23 <leezu> Without: 0x0000007f6374fce8 in list_delinit (item=<optimized out>) at ../src/util/list.h:110

17:23 <leezu> 110 ../src/util/list.h: No such file or directory.

17:23 <leezu> With: 0x0000007f613b1ce8 in list_delinit (item=<optimized out>) at ../src/util/list.h:110

17:23 <leezu> warning: Source file is more recent than executable.

17:23 <leezu> 110 item->prev->next = item->next;

17:23 <robclark> probably just down to how much compiler inlines things.. it is the same thing in both cases

17:23 <robclark> I use something like this to run non-system mesa: LIBGL_DRIVERS_PATH=$p/debug/b/lib64/dri LD_LIBRARY_PATH=$p/debug/b/lib64:$LD_LIBRARY_PATH

17:27 <leezu> Thank you. LIBGL_DRIVERS_PART was missing on my end. Adding that, and using mesa-installdir/lib/aarch64-linux-gnu for the LD_LIBRARY_PATH makes firefox use the non-system mesa. With that, the khronos test passes meaning so your fix worked

17:31 <leezu> robclark: Do you think the fix can be added to upcoming 22.2 release?

17:34 <robclark> maybe? I'll tag it so it gets noticed for stable branch

18:12 <leezu> robclark: I'm running the Khronos tests and have another crash, but it's not as easy to reproduce: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6997

18:26 <leezu> That one may be due to a threading issue?

18:28 <robclark> narrow it down to some particular test?

18:30 <leezu> No, running individual tests always works but running the whole testsuite crashes at some point. The first backtrace was early at the 7th test group, the second backtrace took a couple minutes of running through the testsuite

19:25 <hexdump01> leezu: just a note - in case you are still using my image - i'm for some systems which need newer mesa symlinking /usr/lib/<arch>/dri to /opt/mesa/lib/<arch>/dri and set the ld patch so that the newer /opt/mesa is used - i guess you are not using this anymore, but just in case for you to know to avoid debugging into the wrong direction

19:26 <hexdump0815> leezu: just a note - in case you are still using my image - i'm for some systems which need newer mesa symlinking /usr/lib/<arch>/dri to /opt/mesa/lib/<arch>/dri and set the ld patch so that the newer /opt/mesa is used - i guess you are not using this anymore, but just in case for you to know to avoid debugging into the wrong direction ... afk for a while now

20:33 <leezu> robclark: Thank you for the second fix. With that, I'm able to generate yet another crash: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7004

20:41 <robclark> yeah, that is memory corruption

20:42 <robclark> I tried asan but firefox seems somehow unhappy with that

20:42 <robclark> got the webgl conformance tests running under chromium and so far not hitting any issue like that

20:42 <robclark> so idk, could be ffox nightly issue

21:05 <leezu> I'll try to get an asan build https://firefox-source-docs.mozilla.org/tools/sanitizer/asan.html#creating-try-builds

21:11 <robclark> fwiw, locally I got a very different backtrace, but same `info->canary == CANARY` assert failed

21:11 <robclark> so some sort of use-after-free or that sort of thing

21:52 <leezu> robclark: will you rebase the merge request or does the bot handle that automatically?

21:55 <robclark> margebot handles that (or complains if there are conflicts)

21:57 <leezu> Nice

23:42 <steev> bamse: i bumped to 20220804 of next, still no luck with gpu, but i noticed the disp0_cc_mdss_dptx3_pixel0_clk_src seems to get stuck - https://paste.debian.net/1249363

23:49 <qzed> steev: is suspend working on the x13s?

23:49 <steev> qzed: with the patch from mani_s, yes

23:50 <steev> https://github.com/steev/linux/commit/9ec798bf7b9239a29eefa66d6cca345926f31cd0 i think is the workaround that bamse thinks is good enough to be accepted upstream

23:50 <qzed> oh nice, I'll need to have a look at that then, maybe I can make it work on the sc81810x

23:50 <qzed> thanks for the pointer

23:50 <steev> :)

23:50 <steev> i hope so too

23:50 <steev> i watch your work for my flex stuff ;)

23:51 <qzed> heh, I was just looking over you next branch for the x13s and noticed quite a bunch of PCIe stuff, so I figured I'd ask

23:52 <steev> si, although most of it doesn't apply anymore > 0722

23:52 <steev> i just... left them off, and it seems to boot okay, though there is some complaint about a missing phy

23:53 <qzed> hmm, I guess I'll have to give it a try on 0722 then first

23:53 <steev> well, you do have a branch there already

23:54 <qzed> yeah, and with the remoteproc patch by mani that should now work properly

23:54 <steev> si!

23:55 <steev> i THOUGHT jhovold's pcie patches were sent to the list, i swear that i saw a convo about fixing "something" before trying again or whatever, but i'm not finding them in patchwork

23:55 <steev> maybe it was a different patchset though

23:55 <steev> and he was just commenting