08:21 <LiangQi[m]> 8-9 packages, after trick 1, 99-Phased-Updates, only the grub-efi and shim things left. then trick 2 helped me.

08:24 <icecream95> robclark: I'm seeing Firefox hangs with (website-embedded) Google Maps. For example, go to https://thetruesize.com/ and zoom into a region inside an overlaid country shape

08:24 <icecream95> (I'm using the Firefox snap channel latest/candidate/core24, and mesa-2404 channel latest/beta/kisak.)

08:25 <icecream95> (So that's Mesa 25.0.2)

08:26 <icecream95> There seem to be a couple of threads stuck inside alloc_batch_locked, so I guess the flushing isn't working correctly

08:48 <icecream95> Oh I see... I think it might be that we have two threads trying to flush the same batch at once... so it is never destroyed since at any point in time, at least one of them holds a reference

08:54 <icecream95> Or in other words, there is a problem since the scopes of the locks for ctx->screen and flush_batch are incomparable... neither is nested inside the other

09:05 <icecream95> So the obvious fixes are to execute alloc_batch_locked entirely under the screen lock, or to add state to the batch, say, is_flushing, and pick another flush_batch if that's set

09:07 <icecream95> A more fundamental issue seems to be that you can get a complete deadlock if more than 32 threads need batches at once.

09:20 <icecream95> (maybe. I haven't looked closely enough to be sure)

10:33 <tobhe_> LiangQi[m]: I pushed an update that should have fixed the grub problem. phased updates should not prevent release upgrades afaik

11:12 <icecream95> Debug builds of Mesa give this crash (but the above issue happens even with TC disabled): https://0x0.st/84Xc.txt

11:55 <icecream95> The second fix I suggested doesn't work because I get random crashes (probably from races), but even with a hacky mutex added ( https://0x0.st/84Xe.patch ) and TC disabled, I still get occasional crashes.

11:56 <icecream95> So I think the whole idea of just being able to flush any old batch is broken when there multiple threads using the GL

12:47 <robclark> icecream95: it would be easy enough to raise the limit from 32 to 64 for 64b builds, but making the limit arbitrary would add a lot of draw overhead (since we are using a bitmask as a fast hashset).. but I guess/hope that is more of a theoretical problem and that ffox isn't actually using 32+ threads for rendering. Re: multiple threads flushing, I'll have to look into that, but might not have time today

12:49 <icecream95> robclark: No, there's just Renderer, CanvasRenderer, and TC threads involved here... so yes that is more theoretical

12:52 <icecream95> I wonder however if using a hashset is really much better than a list, since I guess most resources will only be in a single unsubmitted batch at once

13:44 <robclark> the tc threads kinda don't count, it is really about # of ctx's

16:53 <robclark> bamse, konradybcio, etc: have you managed to use gdb+kgdb from an aarch64 device to debug another aarch64 device? For me, gdb seems confused about the debug syms... it can load them but I guess the addresses are somehow wrong? https://www.irccloud.com/pastebin/9e6HIwNO/

17:01 <konradybcio> robclark haven't tried that..

17:04 <robclark> kdb on device seems ok.. but obviously a lot more limited than gdb

17:17 <travmurav[m]> For anyone interested in EL2/slbounce: Given we recently confirmed gunyah is broken as well as that preloaded adsp-lite could possibly help in el2, I've decided to send el2 overlays upstream: https://lore.kernel.org/all/20250501-sc-el2-overlays-v1-0-9202e59e3348@trvn.ru/

17:17 <travmurav[m]> This patchset also generates -el2.dtb for each WoA device so the overlay can be compile tested but also so it's just available easily (and well, otherwise the symbols aren't compiled anyway)

17:18 <travmurav[m]> CC'd Jens Glathe and maz who I know use el2 actively on some devices but if anyone else wants to provide tested-by I'd appreciate that too

17:21 <JensGlathe[m]> Nice

17:21 <travmurav[m]> Depending how that goes I will probably see how to streamline using slbounce itself a bit later

17:23 <travmurav[m]> (also note that those overlays have changed slightly from what I have in slbounce repo as I now have proper access to symbols, i.e. added few missing pcie for x1e too)

17:25 <travmurav[m]> almost missed one pcie as in x1e dtsi most of them are called pci@XXX but one is pcie@XXX :^)

19:44 <bamse> robclark: i've used kdb, haven't tried kgdb...i tried figuring out "crash" a while back, with results similar to yours

19:45 <bamse> travmurav[m]: nice, i like that

19:45 <robclark> ok.. yeah, kdb works ok for me.. just not super featureful

19:48 <bamse> right

19:56 <jdb> Hi, I'm getting this error message "msm_dpu ae01000.display-controller: [drm] Cannot find any crtc or sizes", any ideas about the possible cause(s)?

19:59 <jdb> It happens for both the built-in screen and when plugging an external screen on the USB-C ports, this is on a Surface Pro 9 5G (arcata)

20:02 <JensGlathe[m]> jdb which kernel do you use, do you use the dtb that is upstream?

20:02 <jdb> I'm running a linux image built from jhovold repository, using the branch wip/sc8280xp-6.15-rc4

20:02 <jdb> I'm using the upstream kernel, indeed, I was the one who submitted it ;-)

20:02 <jdb> the upstream dtb I mean

20:04 <jdb> for the built-in screen, I've never been able to make it work, I haven't found yet the correct panel description

20:06 <jdb> for the external screens, it used to work quite reliably but I can't figure out what happens now, I can't get them enabled (on v6.12, v6.14 and today on v6.15-rc4)

20:08 <JensGlathe[m]> Hi Jerome

20:09 <JensGlathe[m]> You could try my 6.15.0-rc4-jg-1, soon to be uploaded

20:09 <jdb> sure, happy to give it a try

20:11 <jdb> I'm wondering if I'm not missing something else in my Debian setup, some modules or a config in my kernel build maybe

20:13 <JensGlathe[m]> I re-applied v4 of the LTTPR patch from alexVinarskis , this showed an improvement on the Snapdragon DevKit - sjowing output much earlier

20:23 <JensGlathe[m]> it's [uploading](https://drive.google.com/drive/folders/1Lps5o3FXroAJFDiKj18vutJbC1uld49s)

20:40 <jdb> I need only 2 .deb packages, linux-image and linux-modules, right?

20:41 <JensGlathe[m]> I always do sudo dpkg -i *.deb in the directory

21:09 <jdb> JensGlathe[m]: with your image, I get a reboot after a few seconds if I load the msm module, and the screens are not enabled

21:09 <JensGlathe[m]> wow bad

21:11 <jdb> I can boot with module_blacklist=msm though, my backup option for the moment

21:16 <JensGlathe[m]> hmm why do you enable dispcc1 in the dt

21:18 <JensGlathe[m]> Also, internal display actually should be mdss0_dp2 and mdss0_dp2_phy, or like the thinkpad x13s

21:19 <jdb> with some older kernels and the msm module blacklisted, I was able to keep the built-in screen enabled with efifb at least, but this doesn't work anymore (or not the same) with more recent kernel versions

21:19 <jdb> the bring-up is complex without a working screen...

21:21 <jdb> I would need to dive into my memory / archives, I created / updated the .dts many months ago and it was working at that time

21:22 <jdb> (and I did test many different configurations, based on yours, on x13s, on the CRD at that time)

21:22 <JensGlathe[m]> I would check against the x13s dt (which has panel-edp) but maybe on mdss0_dp2

21:25 <jdb> thanks for the suggestion, I'll give this a try, and I will also look at the devicetrees for the Surface Laptop 7 and the Surface Pro 11, that may give me another hint

21:25 <jdb> step by step, enough for tonight