00:11 memleak: just realized this is probably a good place to share this, lol: https://dpaste.com/EQM5M6WK2
00:15 memleak: system just crashed actually even with pm+suspend on, it does it occasionally
00:16 memleak: i don't think the fedora rawhide 6.19-rc8 kernel has crashed for me yet
00:16 memleak: so it's probably my unique kernel config, i have it very trimmed down.
07:59 tzimmermann: MoeIcenowy, https://lore.kernel.org/dri-devel/202602060154.ONBYvM9m-lkp@intel.com/T/#u
08:33 javierm: tzimmermann: it's a suprise to me that in drm the changelog is kept as a part of the commit message (from your answer to Tzung-Bi)
08:33 javierm: I've always put the changelog between the --- separator and the start of the actual diff
08:34 tzimmermann: it's not that important. but also not uncommon
08:34 javierm: tzimmermann: yeah, I was wanted to know what the convention was to follow from now on
08:34 tzimmermann: do as you like :)
08:34 javierm: Ok :)
09:46 pq: javierm, IMO, more information never hurts. Over 10 years ago IIRC Ingo Molnar merged a patch from me with a whole email thread as the commit message. :-P
09:47 pq: well, just one email, but with all the quotes and discussions in it.
09:54 tzimmermann: plot twist: the actual change was a one-liner :P
09:55 sima: yeah, those are the best commits, just epic story for the one true change :-D
09:56 pq: oh! I had forgot that. :-D
09:56 pq: tzimmermann, you remembered what I was talking about?
09:57 tzimmermann: no, not at all. it was a joke. but it looks like i hit the nail on the head
09:58 pq: hmm, I don't think it was a one-liner...
09:59 pq: anyway, it happens :-)
10:00 pq: and given the difficulty of digging up the development history of a patch after merging it, carrying the changelogs might be a good thing.
11:57 stsquad: do you track message-ids in commits? Thats how we track the history of a patch in QEMU (but we are very list focused for development)
11:57 emersion: we add a "Link" tag to lore.kernel.org
11:58 emersion: dim (DRM maintainer tool) adds it automatically
11:59 emersion: we don't have a trailer for Message-Id (it can be recovered from the Link trailer, but not in a standard way - e.g. these were patchwork links before)
14:53 alyssa: i sure do love when a test passes under sim but not hw
14:53 glehmann: imagine having a sim
15:40 mattst88: glehmann: you're just missing a source of misinformation :P
17:57 openglfreak: Hello, I'm having some issues with user queues on AMD (7900 XTX, mesa git, Linux 6.19-rc8): -When I run `AMD_USERQ=1 glxgears` and press Ctrl-C, the application takes a long time to exit, about a second or so; doesn't happen without userq -When I run `AMD_USERQ=1 picom --backend egl` my whole desktop freezes irrecoverably; also doesn't happen without userq
17:58 openglfreak: I have an implementation of user queues for RADV and I'm encountering very similar issues there, maybe someone has some idea what could be going wrong?
19:30 agd5f: openglfreak, you need this patch set: https://lists.freedesktop.org/archives/amd-gfx/2026-February/137958.html
20:00 openglfreak: agd5f Thank you! I will try that out
21:12 openglfreak: I tried to add drm-next to my kernel to add those patches and now I'm getting "Fatal exception in interrupt". Welp.
21:15 mareko: tarceri: yes, in the issue
22:34 openglfreak: I picked just the patches from drm-next that are necessary to apply that patch set and I'm getting what seems to be combined gpu and kerrnel crashes now