01:03 kode54: um
01:03 kode54: speaking of r535 firmware
01:03 kode54: when I attempt to boot 6.19 on my blackwell gpu, the log where it crashes is preceded by some firmware init function with "r535" in the name
01:07 mhenning[d]: that may be normal. Some of the functions that are shared by r535 and r570 are named r535
01:16 kode54: must be something else then
01:17 kode54: I can't exactly get good results out of linux-mainline, either, unless I apply a mt76 patch too
01:18 kode54: I also picked exactly the wrong distribution to switch to, because the founder doesn't care about nouveau
03:56 _lyude[d]: gfxstrand[d]: happy new year! I don't know if you remember that cursor bug , and I'm not 100% sure about this but I have a very strong hunch this fix I posted for a different issue might actually fix it:
03:56 _lyude[d]: https://patchwork.freedesktop.org/series/159325/
06:14 matt_schwartz[d]: kode54: https://lore.kernel.org/regressions/59736756-d81b-41bb-84ba-a1b51057cdd4@linux.dev/T/#u this is why i cant boot into 6.19 on blackwell fwiw
06:14 matt_schwartz[d]: i cant get logs of the crash with my setup at the moment
06:14 matt_schwartz[d]: well, freeze in my case
06:57 kode54: oh, so I'm not alone
06:58 kode54: I don't get a complete freeze, but instead I get an OOPS that kills the GPU, leaving the machine completely blinded
06:59 kode54: and if I don't patch the kernel for the mt76 fortify issue, I get no working network even if I do log in
07:00 kode54: bonus points for not being able to tell I'm past LUKS because there's no display
07:00 kode54: maybe I can try to help out with this debugging
07:01 kode54: I'll look at what you found, you did a hell of a lot more than I did
07:01 kode54: all I could do was pull logs :[
07:45 kode54: dang it
07:45 kode54: I don't know how to figure out how an offset resolves into a struct member, when the structs that are involved are nested multiple levels deep with structs from everywhere
07:46 kode54: and apparently this one offset divining tool requires the source dir it's probing to already have been built
07:52 kode54: somehow it looks like a null nvkm_bios is being passed to bit_entry
08:38 karolherbst[d]: oops.. I put the sender on the discard list but accepted the spam message 🙃
08:41 kode54: :[
08:42 kode54: pobody's nerfect
11:53 esdrastarsis[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1455891603200802978/Screenshot_2025-12-31_08-52-10.png?ex=69566037&is=69550eb7&hm=15c9ea5de54f52b3a0e75711146865911964ef07f9fc9900dff1ea1f9dc23648&
11:53 esdrastarsis[d]: esdrastarsis[d]: Added capabilities from nvk_video.c code and uh...
17:41 jja2000[d]: Funny thought, considering the Tegra X2 talk from 39C3, SteamOS on the Magic Leap 1
19:27 _lyude[d]: matt_schwartz[d]: oh dear
19:28 _lyude[d]: i wrote that commit, hold on let me see if I can come up with a patch real quick
19:30 matt_schwartz[d]: in case it helps, was just testing with this based on kode's logs which seems to work, but not sure if it regresses the bug you fixed or breaks other stuff: https://gist.github.com/matte-schwartz/afac31e3b175d08b8c43e01085c30d0f
19:32 _lyude[d]: oh - matt_schwartz[d] actually that looks just fine to me, I can spin up a build on my desktop at home real quick and try it
19:32 _lyude[d]: matt_schwartz[d]: mind sending to the dri-devel mailing list and adding me in the To: (lyude at redhat dot com) ?
19:33 matt_schwartz[d]: yeah sure, was going to test a bit more before submitting it for review
19:33 matt_schwartz[d]: there’s also a new regression I need to bisect where there’s corruption between Plymouth and SDDM now but that’s for later :frog_sweat:
19:34 _lyude[d]: if you're testing any display related stuff it's worth trying the cursor hang patch I posted on the mailing list as well. I have a feeling there are a lot of fun and creative ways that issue can make various things fail or look corrupted
19:35 matt_schwartz[d]: cursor would make sense actually based on the timing of when I see it, will give it a try.
20:42 _lyude[d]: matt_schwartz[d]: actually I realized your patch needs a change: the fwsec scrubber firmware needs to be allocated earlier then the first time it's used, so if you can move it to the end of initialization of the driver that would be better. There's no guarantee we can allocate a large enough contiguous buffer later on during runtime otherwise
20:46 _lyude[d]: (I assume that's what fwsec-sb stands for but I could be wrong)
20:46 _lyude[d]: Basically: we don't actually use fwsec-sb for the first time until the resume code path (where the system could have hit high memory pressure already), hence why we want to make sure we allocate the memory at the end of init and not the first time we use it
20:52 matt_schwartz[d]: ah, that makes sense. will try your idea.
21:11 kode54: was my diagnosis anything other than completely wrong?
21:55 matt_schwartz[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1456043148101947636/0001-drm-nouveau-gsp-move-fwsec-sb-init-to-tu102_gsp_onei.patch?ex=6956ed5a&is=69559bda&hm=a7b6b22d8b720d88bd89a52e95b91912ee4859981b9ba977b66b8ee896c9e0a4&
21:55 matt_schwartz[d]: _lyude[d]: i think this should be better
21:59 matt_schwartz[d]: or happy to leave it to you if you have a better idea of where to put it