00:04mangodev[d]: mhenning[d]: building this right now, hoping it'll fix latest
00:04mangodev[d]: do you think this'd be more of an NVK thing or more of a nouveau thing?
00:05mhenning[d]: I'm not sure at a glance
00:06mhenning[d]: It looks like it's something UAPI related but I'm not sure if userspace is setting up things wrong or if the kernel needs to implement something additional for it to work
00:10mangodev[d]: mhenning[d]: uh oh
00:10mangodev[d]: still broke
00:10mangodev[d]: must be another change from today
00:11mhenning[d]: okay. If you could get a bisect, that would be helpful
00:14mangodev[d]: uhhh dumb question but
00:14mangodev[d]: how do i find what commit my working driver is based off of?
00:15mangodev[d]: my current working driver is `Mesa 26.1.0-devel (git-53b879ac58) (LLVM 21.1.6)`
00:16mhenning[d]: 53b879ac58 is the commit hash for that version
00:16mhenning[d]: It's just the string after `git-`
00:54mangodev[d]: mhenning[d]: doesn't seem to be the SHA hash because it's the wrong length
00:54mangodev[d]: it's too short (or at least the one gitlab provides)
00:54mangodev[d]: and the one in the url is *wayyyy* too long
00:55mangodev[d]: oh i just realized it's just truncated
00:56mangodev[d]: oh…
00:56mangodev[d]: i have a lot of searching to do
00:56mangodev[d]: i thought i built my driver yesterday
00:56mangodev[d]: it's from january 22nd 🫠
01:03mangodev[d]: between the driver build i have working and current main, i have two primary suspects i'm gonna test for
01:03mangodev[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38502
01:03mangodev[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39475
01:09mangodev[d]: first one not it
01:13mhenning[d]: mangodev[d]: yeah, a lot of git stuff works fine with truncated hashes. eg. you can `git show 53b879ac58` and it will do the right thing
01:13mangodev[d]: interesting
01:13mangodev[d]: -# i definitely need to work with git more
01:14mangodev[d]: i'd assume if the build before suspect 2 works, then i test the suspect commit itself, then post it as an issue?
01:15karolherbst[d]: well it just checks if there is a hash starting with it and fails if there is a conflict
01:15mhenning[d]: mangodev[d]: Yep, if you can narrow it down to one commit and post an issue that would be great
01:16mangodev[d]: uh oh
01:16mangodev[d]: might have a lead
01:16mangodev[d]: commit before suspect 2 works
01:16mangodev[d]: let's see if suspect commit 2 breaks it
01:17mangodev[d]: mhenning[d]: do i post the broken commit, the working commit, or both?
01:19mhenning[d]: typically the broken commit, since that's the first one with the issue
01:19mangodev[d]: okay, just making sure
01:19mangodev[d]: i want to make things as easy as possible to diagnose
01:21mangodev[d]: i'm concerned about this commit because they said they only tested it through CTS
01:22mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1465879638499790899/rn_image_picker_lib_temp_339e4fe3-fd88-467d-b978-92d2bc283fe6.jpg?ex=697ab64c&is=697964cc&hm=0488a972de7ac824a80574549e48d5176d0f8cd4dbad015eb763f5fad9f72002&
01:22mangodev[d]: I FOUND IT!!!
01:22mangodev[d]: mr 39475 breaks kwin
01:22mangodev[d]: (at least through zink)
01:23mangodev[d]: mangodev[d]: and the error is already here
01:23mangodev[d]: i'll try getting text logs if the logs don't corrupt on reboot
01:24mangodev[d]: i've never felt so good about a broken system before :D
01:37mangodev[d]: mhenning[d]: [posted](https://gitlab.freedesktop.org/mesa/mesa/-/issues/14746)
01:44mhenning[d]: great, thanks
01:47mangodev[d]: :D
02:49airlied[d]: mhenning[d]: marysaka[d] https://lore.kernel.org/nouveau/20260128024806.1534662-1-airlied@gmail.com/T/#u
02:49airlied[d]: it's a bit more heavyweight than the previous one
03:13mhenning[d]: Okay, will test tomorrow
07:59marysaka[d]: Will let my testbench run this with the reproducer for the day and see if it triggers
10:07marysaka[d]: airlied[d]: still faulting here with mel reproducer and my python script:
10:07marysaka[d]: Attempt 178 successfully crashed, ending here
10:07marysaka[d]: Crashed in 5310~5340s!
10:07marysaka[d]: ➜ mesa git:(main) ✗ sudo dmesg | grep nouveau | tail -5
10:07marysaka[d]: [ 876.451823] nouveau 0000:09:00.0: [drm] fb0: nouveaudrmfb frame buffer device
10:07marysaka[d]: [ 7651.106785] nouveau 0000:09:00.0: gsp: mmu fault queued
10:07marysaka[d]: [ 7651.110784] nouveau 0000:09:00.0: gsp: rc engn:00000001 chid:134 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000003ffdf00000 fault_type:00000002
10:07marysaka[d]: [ 7651.110806] nouveau 0000:09:00.0: fifo:c00000:0086:0086:[deqp-vk[49284]] errored - disabling channel
10:07marysaka[d]: [ 7651.110832] nouveau 0000:09:00.0: deqp-vk[49284]: channel 134 killed!
10:07airlied[d]: Can you try and reproduce with trace?
10:08marysaka[d]: will do that now
10:09airlied[d]: I got successful runs where I delayed all unrefs by 500us and I ended up with 1000s of refs to cleanup, but maybe there is another problem then
10:10marysaka[d]: yeah... with mel reproducer we are firing up 100 parallel deqp-vk so maybe something else is lurking
10:10marysaka[d]: airlied[d]: I do have some previous full logs with MMU debug logs if you want that now actually
10:11airlied[d]: Id want them with the v2 patch
10:12marysaka[d]: okay will run that again then
10:14karolherbst[d]: tried running a debug kernel? They sometimes report invalid uses of kernel APIs, which might only happen under high concurrency
10:16marysaka[d]: that might be a good idea... I will try that next I guess
10:29airlied[d]: I think this is just buggy spt and lpt handling
10:30airlied[d]: Barely uses kernel API since it's in nvkm
11:58marysaka[d]: okay got a crash just now, will compress the log file hopefully it's not too big...
14:49trenderviasat: nice mr could had been january 22 indeed, this should work however I have better my own I saw iphone glitching, can you post some more recent mrs? I am unsure I left the mr open in some similar date which was correct but I have better.
15:13ericoscarwiggley: airlied has todays one, it’s family phone all storage in icloud, are you seeing things now, or want me to explain?
22:41mhenning[d]: mangodev[d]: When you get a chance, could you test https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39598 and see if it fixes SDDM for you?
23:13mangodev[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1466209611521720401/rn_image_picker_lib_temp_569265ed-93dc-42a3-ac36-0b9e57fad96b.jpg?ex=697be99c&is=697a981c&hm=f41ffbfd50ddfbbbeb185f676f9a81e3efbc97ad9b30d4a14a6f3914a24cf388&
23:13mangodev[d]: mhenning[d]: fixed it 👍
23:13mangodev[d]: ty :D
23:14mangodev[d]: how did you find a fix that fast though
23:14mangodev[d]: tbf it was a single commit that was relatively small
23:14mangodev[d]: but still
23:16mhenning[d]: It was a bit of a guess - I was just looking at the patch from the bisect and I noticed everything else in the file specified a queue for wl_display_roundtrip and the new call didn't
23:16mhenning[d]: It took a bit more reading to make sure the fix was correct, but yeah we definitely want to specify the queue there
23:24karolherbst[d]: snowycoder: any idea why you choose to make OpViLd::off an i8 and not i16?
23:24karolherbst[d]: ohh.. I just saw it was reduced to 8 bit in the later kepler archs...