00:06mangodev[d]: esdrastarsis[d]: is it? i thought the MR was dormant for some months
00:07mangodev[d]: I'll check again, but it hasn't shown up in recently updated for nvk in a long time
00:07esdrastarsis[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1463324044852989964/Screenshot_2025-12-29_07-06-04.png?ex=69716a37&is=697018b7&hm=dfa2ab78d0533d797dff74ce030a769801d6782ad0d2b395c68ee04c2e4ad145&
00:07esdrastarsis[d]: mangodev[d]:
00:07esdrastarsis[d]: I did a rebase
00:08mhenning[d]: Yeah, nobody's been focusing on it lately
00:10mangodev[d]: yes, there's larger issues to focus on right now
00:11mangodev[d]: i hope that arm dev's zink bugfixes could be merged by the end of this week or so, given one is already merged
00:12mangodev[d]: crazy to see anyone other than zmike doing code plumbing in there, the way he's described it before sounds like hell
00:13mangodev[d]: i am excited about the work on the faults
00:13mangodev[d]: although i'm kinda bummed out that large pages are pushed to be a later thing
00:14mhenning[d]: I think it's still undecided if large pages will make 6.19 or not
00:15mangodev[d]: i don't mind myself if it arrives in 6.20, given i can't game on my current install regardless
00:16mangodev[d]: i'll reinstall some time in May or June, which should help my system performance
00:16mangodev[d]: and by then, NVK should be more usable
06:12travisbreed: intel and red hat will be charged for the terror and conspiracy they committed for not knowing how to code on top. Fecalherbst will never get any job again. My personal opinion is that you get hit by artillery perpendicular as to what you did to me artillery such as the talked hypersonic missile. I continue to silence all the bulls cheaters and illborn people around me by force, we have
06:12travisbreed: stacks of work to do, cause to be idiot is easy and there are many to go. meanwhile those companies target my computer with viruses consistently harassing and extorting for money on top. pegasus surveillance implanted time to pay, ou yeah right , sure for quasimodos it’s easy to commit conspiracy but you all will be made responsible of those grouped attacks, it’s much harder to invent and
06:12travisbreed: make sense too, to create, to offer etc.
06:12airlied[d]: marysaka[d]: I think the problem is we transition the LPTE to invalid wrongly after we unref SPTEs
06:31airlied[d]: Killing the invalid callback seems to fix it, need to think about this a bit more 🙂
07:59marysaka[d]: airlied[d]: Yeah that was my understanding of it, I think the refcounting here was never meant for a pattern of unmap, ref, map, unref as before “raw” methods we only had get_map and unmap_put to begin with
08:00marysaka[d]: Will try to think about it too today
08:01airlied[d]: Like the LPT should at least be valid in this case we just have to avoid changing its state on the spt unmap
08:05marysaka[d]: I wil ltry to understand the refcouting a bit more but we might just not be checking enough when unmap_sptes is called tbh
08:11marysaka[d]: mhenning[d]: if we cannot fix it for 6.19 release, let's disable it until we land a patch that fix the bug and add a proper uAPI querying support or not for it
08:11marysaka[d]: but I'm still confident we could do something before it
08:51marysaka[d]: airlied[d]: I'm pretty confident of my claim that the current code for VMM doesn't account for unref of old mapping after refo the new mapping
08:52marysaka[d]: the issue seems more like nvkm_vmm_ref_hwpt detect that the previous mapping because of NVKM_VMM_PTE_SPTES being set I think
08:53marysaka[d]: maybe NVKM_VMM_PTE_SPTES should be cleared in the other path for those pte I'm not too sure yet....
08:53airlied[d]: I think we should fix the vmm code to be happy with any order of refs but we might need to write more tests
08:58marysaka[d]: we could try but I have a feeling this will requires quite a bit of rewrite
08:59marysaka[d]: but hopefully I'm wrong
13:59l4mRh4X0r_: Hi, at my workplace they have these USB-C hubs with a HDMI port on it, but whenever I plug it in, GNOME recognises and activates the screen, but the monitor says it's not getting a signal. The monitor works fine when directly plugged into my laptop's HDMI port. I also get the kernel message nouveau 0000:01:00.0: disp: outp 02:0006:0f48: training failed.
13:59l4mRh4X0r_: My laptop is a Lenovo ThinkPad P50 with a Quadro M1000M that's connected to the external screen outputs
14:00l4mRh4X0r_: Is this an issue with nouveau, or is this just the hardware?
14:01l4mRh4X0r_: (or some other issue with my setup)
14:05karolherbst: l4mRh4X0r_: because it's your workplace, do you run an LTS distro with an older kernel, or is the kernel upstream supported?
14:06marysaka[d]: airlied[d]: so we were not refcounting large page in `nvkm_vmm_pt::pte`, this fix the specific fault we were seeing but a full CTS reveal other random faults, this time with a granularity of 4K.
14:06marysaka[d]: I think this show that `nvkm_vmm_pt::refs[0]` is likely missing some refcounting for the small page case (refs[0] tracking LPT for reference)
14:06marysaka[d]: In any cases, will stop for today but this is my small patch for the initial issue, hopefully I didn't miss anything in my understanding of this https://gitlab.freedesktop.org/marysaka/linux/-/commit/6dc3171bf3af1886518ceb3884234c0e0dc51205
14:06karolherbst: upstream supported as in, it's an official lts branch of the linux kernel
14:07karolherbst: might just want to run "uname -a" or whatever
14:07l4mRh4X0r_: karolherbst: It's bring your own laptop, I use Arch Linux on kernel 6.17.9-arch1-1
14:07karolherbst: ahh, I see
14:09karolherbst: l4mRh4X0r_: Lyude might want to take a look, but not sure if she has time. Probably want to file a proper issue at https://gitlab.freedesktop.org/drm/nouveau/-/issues/ and attach your dmesg as there might be more relevant information there
14:09karolherbst: anyway, it's probably an issue with nouveau
14:09l4mRh4X0r_: Alright, thanks. I'll do that then
14:10karolherbst: l4mRh4X0r_: is it a HDR high refresh rate, high resolution display? I know that at some higher resolution+refresh rates DisplayPort support becomes a bit more flaky
14:10l4mRh4X0r_: Nope, it's a (rather old) HP EliteDisplay E222
14:10karolherbst: mhhhhh.. weird...
14:11karolherbst: some docks are weird... do you know if the laptop's HDMI port is connected to the nvidia or intel GPU?
14:12l4mRh4X0r_: It's connected to the nvidia GPU, all external ports are
14:12karolherbst: okay
14:13karolherbst: l4mRh4X0r_: is it one of those official lenovo hubs?
14:13l4mRh4X0r_: Nope, it's a cheap-ish UGreen hub
14:13l4mRh4X0r_: https://eu.ugreen.com/products/ugreen-revodok-6-in-1-usb-c-hub-ethernet-4k-60hz-hdmi-display
14:14gfxstrand[d]: mangodev[d]: I was working on it for a while. It's pretty broken at the moment, unfortunately.
14:14gfxstrand[d]: It plays some videos but crashes and burns on the CTS
14:16karolherbst: I see. Maybe Lyude (or others) might take a look, because I'm not that familiar with the display side of things anyway
14:17l4mRh4X0r_: I'll need to create the issue at a later point, the boot has already been rotated from my dmesg 🥲
14:18karolherbst: can always use "journalctl --dmesg --no-hostname"
14:37l4mRh4X0r_: Fair enough
15:13l4mRh4X0r_: https://gitlab.freedesktop.org/drm/nouveau/-/issues/474, let me know if I failed to provide something important
15:21karolherbst: l4mRh4X0r_: "and other displays work fine over USB-C" meaning different displays work fine with the same hub and the same USB-C port and the same port on the hub?
15:21l4mRh4X0r_: Ah, no, let me clarify that
15:22karolherbst: ahh yeah..
15:24karolherbst: anyway yeah.. looks like a bug in the driver somewhere
15:24karolherbst: "USB-C displays" okay, so DisplayPort over USB-C works fine. That's good to know
15:25karolherbst: l4mRh4X0r_: have you tried if USB-C displays connected to the dock work fine?
15:25karolherbst: not sure if the hub supports that tho...
15:26karolherbst: but it should.. in theory
15:26l4mRh4X0r_: I'm not sure either, I don't have a USB-C display at hand at my workplace
17:25mhenning[d]: marysaka[d]: right, I'm just nervous about how little time we have for the fix and testing right now, since we're already up to rc6.
17:26mhenning[d]: even if we get a patch landed this week, that gives us ~ a week to test before release
17:26mhenning[d]: if we drop it for 6.19 then the time pressure is gone
17:27marysaka[d]: we could very well just drop it for now on the userspace side and add a proper way to know if comp is supported (without the version)
17:29marysaka[d]: tbh the original fix that ensured ordering would have been enough to avoid any buggy path and I still believe that we should not be deferring unref and invalidation after signalling the job fence, that could make thing inconsistent :AkkoShrug:
17:32mhenning[d]: yeah it does seem odd to me to signal the fence before the unmap's page table updates take place
18:24airlied[d]: Unmap should happen before fence, unref not so much
18:26airlied[d]: Unref should just update refcounts and free unused objects, it's just spt/lpt refcounting is broken
18:29mhenning[d]: ah, okay. I suppose I was misunderstanding earlier discussion then
19:50Duke``: <karolherbst> l4mRh4X0r_: have you tried if USB-C displays connected to the dock work fine? <-- it does not (the ugreen page says so and I can confirm, I own one...)
19:51Duke``: 1. The 10Gbps USB-C data ports do not support media display and PD charging functions.
19:51karolherbst: ahh, good to know
21:50Duke``: l4mRh4X0r_, karolherbst: just in case, I tried on my side the ugreen usb-c hub with an HP zbook (i7-13850HX, RTX 2000 Ada) and I can get display working both with HDMI on laptop and HDMI on hub, usb-c DP on laptop works too, and all that works either in hybrid or discrete only mode. I tried that with an Ubuntu 25.10 (and the nouveau driver of course).