00:01 fdobridge_: <r​edsheep> Looks like I will have to wait to try to figure out juggling the drivers later, the mirrors for the extra/nvidia arch package are all returning 404
00:33 fdobridge_: <r​edsheep> Nevermind, I just had to fix my mirrors to install it, and go back to Linux 6.6 to boot it. Testing zink on it now
01:18 fdobridge_: <r​edsheep> Stuck again, what is the trick to getting zink to load on top of the nvidia driver? This still appears to be loading the prop driver, and not zink:
01:18 fdobridge_: <r​edsheep>
01:18 fdobridge_: <r​edsheep> ```VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json MESA_LOADER_DRIVER_OVERRIDE=zink prismlauncher```
01:30 fdobridge_: <r​edsheep> At least that launches, but if I load with:
01:30 fdobridge_: <r​edsheep>
01:30 fdobridge_: <r​edsheep> ```VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink prismlauncher```
01:30 fdobridge_: <r​edsheep>
01:30 fdobridge_: <r​edsheep> Then that crashes with ```ERROR: ICD associated with VkPhysicalDevice does not support GetPhysicalDeviceCalibrateableTimeDomainsKHR```
01:30 fdobridge_: <s​amantas5855> I think I did
01:30 fdobridge_: <s​amantas5855> __GLX_VENDOR_LIBRARY_NAME=mesa MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink
01:32 fdobridge_: <r​edsheep> If I skip the ICD path to match yours then I get:
01:32 fdobridge_: <r​edsheep>
01:32 fdobridge_: <r​edsheep> ```DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.
01:32 fdobridge_: <r​edsheep> ERROR: ICD associated with VkPhysicalDevice does not support GetPhysicalDeviceCalibrateableTimeDomainsKHR```
01:32 fdobridge_: <r​edsheep> It doesn't mention NVK without specifying the ICD path
01:33 fdobridge_: <r​edsheep> It doesn't mention NVK when* specifying the ICD path (edited)
07:49 fdobridge_: <S​id> hm, so it's a bug in GSP DRM handling overall
07:50 fdobridge_: <S​id> and not a gen/setup specific once
07:50 fdobridge_: <S​id> and not a gen/setup specific one (edited)
07:50 fdobridge_: <S​id> interesting
07:50 fdobridge_: <S​id> (referring to DEVICE_LOST)
07:59 fdobridge_: <S​id> ok, I have a question I'm hoping someone can answer for me:
07:59 fdobridge_: <S​id> when NVK calls drmCommandWriteRead() in its push_submit, what exactly does the drmCommandIndex refer to and how does the kernel interpret and handle it?
09:59 fdobridge_: <r​edsheep> It's possible there are two different device lost bugs which is why I was trying to test if zink could blow up the prop driver like Karol suggested, but given I played so long error-free prior to the kernel patches I do think they're likely the reason I got that error.
09:59 fdobridge_: <S​id> ..oh?
09:59 fdobridge_: <S​id> in that case I think I know which patch introduces the error
10:01 fdobridge_: <S​id> give me ~30 mins to verify
10:01 fdobridge_: <S​id> in the meanwhile
10:02 fdobridge_: <S​id> could you try building the patchset without `0010-nouveau-push-event-block-allowing-out-of-the-fence-context.patch` as well? since I need that commit to not run into system-wide hangs
10:02 fdobridge_: <S​id> I have a feeling that's where the device lost error is being introduced
10:03 fdobridge_: <S​id> I'll try building current rc with *only* that commit on top, you could try everything except that commit
10:03 fdobridge_: <r​edsheep> Sounds good
10:03 fdobridge_: <S​id> if I run into device lost and you don't, we have our culprit :D
10:08 fdobridge_: <r​edsheep> Before I can effectively test that I need to figure out disabiling nvidia's driver so I can properly boot the right kernel without uninstalling and reinstalling it all the time
10:10 fdobridge_: <S​id> do you use systemd-boot?
10:10 fdobridge_: <r​edsheep> Yes
10:10 fdobridge_: <!​DodoNVK (she) 🇱🇹> I have this in my kernel optionsl: `module_blacklist=nvidia,nvidia-modeset,nvidia-drm,nvidia-uvm`
10:10 fdobridge_: <!​DodoNVK (she) 🇱🇹> I have this in my kernel options: `module_blacklist=nvidia,nvidia-modeset,nvidia-drm,nvidia-uvm` (edited)
10:10 fdobridge_: <S​id> ```
10:10 fdobridge_: <S​id> [sidpr@strogg entries]$ pwd
10:10 fdobridge_: <S​id> /boot/loader/entries
10:10 fdobridge_: <S​id> [sidpr@strogg entries]$ cat caconv.conf
10:11 fdobridge_: <S​id> title Arch Linux
10:11 fdobridge_: <S​id> linux /vmlinuz-linux-caco
10:11 fdobridge_: <S​id> initrd /intel-ucode.img
10:11 fdobridge_: <S​id> initrd /initramfs-linux-caco.img
10:11 fdobridge_: <S​id> options rw rootfstype=bcachefs root=/dev/nvme0n1:/dev/nvme1n1p3:/dev/sda i915.enable_fbc=1 i915.lvds_downclock=1 i915.enable_guc=2 i915.enable_psr=1 pcie_aspm=force pcie_aspm.policy=performance drm.vblankoffdelay=1 ahci.mobile_lpm_policy=1 module_blacklist=nouveau
10:11 fdobridge_: <S​id> [sidpr@strogg entries]$ cat cacogsp.conf
10:11 fdobridge_: <S​id> title Arch Linux (With GSP)
10:11 fdobridge_: <S​id> linux /vmlinuz-linux-caco
10:11 fdobridge_: <S​id> initrd /intel-ucode.img
10:11 fdobridge_: <S​id> initrd /initramfs-linux-caco.img
10:11 fdobridge_: <S​id> options rw rootfstype=bcachefs root=/dev/nvme0n1:/dev/nvme1n1p3:/dev/sda i915.enable_fbc=1 i915.lvds_downclock=1 i915.enable_guc=2 i915.enable_psr=1 pcie_aspm=force pcie_aspm.policy=performance drm.vblankoffdelay=1 ahci.mobile_lpm_policy=1 module_blacklist=nvidia nouveau.config=NvGspRm=1 intel_idle.max_cstate=1
10:11 fdobridge_: <S​id> ```
10:11 fdobridge_: <S​id> is what's working for me on a prime setup
10:11 fdobridge_: <!​DodoNVK (she) 🇱🇹> That's a lot of i915 stuff 🟦
10:11 fdobridge_: <S​id> you only need to blacklist nvidia, since loading nvidia loads everything else
10:11 fdobridge_: <S​id> power saving memes :frog_gears:
10:12 fdobridge_: <r​edsheep> If I don't have those directories I assume I need to create them to get to /boot/loader/entries/?
10:12 fdobridge_: <S​id> /boot is your ESP partition
10:13 fdobridge_: <!​DodoNVK (she) 🇱🇹> I also had to create a fake nvidia-utils.conf file in /etc/modprobe.d
10:13 fdobridge_: <S​id> yeah, you'll have to check the system to see if nouveau is being blacklisted anywhere and disable that
10:14 fdobridge_: <S​id> ..or actually
10:15 fdobridge_: <S​id> if you use X11 you should be able to just use optimus-manager
10:15 fdobridge_: <S​id> no need to reboot for switching then, you'll just have to log out and back into your session again
10:16 fdobridge_: <r​edsheep> Does that work even if the igpu is disabled and/or amd?
10:16 fdobridge_: <S​id> https://github.com/Askannz/optimus-manager/wiki/A-guide--to-power-management-options#configuration-2--pci-power-control
10:16 fdobridge_: <S​id> it should? I'm not sure
10:16 fdobridge_: <S​id> it doesn't unload the nvidia module consistently for me is all I can tell you
10:16 fdobridge_: <r​edsheep> Optimus is the branding for nvidia+intel so 🤷
10:17 fdobridge_: <r​edsheep> I'll try it
10:17 fdobridge_: <S​id> readme says it works with nvidia+amd as well
10:19 fdobridge_: <r​edsheep> ... I'm reviewing the readme and I am questioning my life choices, I am just going to uninstall the nvidia driver lol
10:19 fdobridge_: <S​id> heh
10:19 fdobridge_: <S​id> I feel like multiple boot options is the best way to do it
10:20 fdobridge_: <S​id> I'm not entirely sure how the boot options will look like if you use UKI though
10:20 fdobridge_: <S​id> or the config for it, rather
10:20 fdobridge_: <r​edsheep> That's valid but my linux install basically exists just to test nvk
10:20 fdobridge_: <S​id> :o
10:21 fdobridge_: <S​id> this machine is my daily driver 😅
10:21 fdobridge_: <r​edsheep> Honestly, I am really not very familiar with linux as a whole, I am just here in hopes that some day I will want to use it. I see the end times coming for me using windows
10:22 fdobridge_: <S​id> that's fair, I get that
10:22 fdobridge_: <S​id> I too have a fair few friends unhappy with the direction windows is taking, planning on jumping ship when win10 goes EOL
10:26 fdobridge_: <r​edsheep> Yeah I did daily drive linux for 8 months and the nvidia driver situation was the final straw that drove me away at the time, it just broke everything.
10:28 fdobridge_: <S​id> I've been using linux for the past 3 years on this laptop and haven't really had too many driver-related troubles, but I suppose that's because of the iGPU doing the heavy lifting
10:28 fdobridge_: <S​id> I don't even have a mux switch 😅
10:30 fdobridge_: <r​edsheep> My personal system exists for tweaking and overclocking so I always have really recent hardware and wacky configs. When testing wayland especially it was blowing everything up. Anyway, I am building the kernel now with patch 10 removed
10:39 fdobridge_: <r​edsheep> ...Something blew up my session mid-build. Seems to be an Nvidia driver bug. Glad to be deleting it.
10:40 fdobridge_: <S​id> :(
10:45 fdobridge_: <r​edsheep> Oh it's building against rc7 now
10:47 fdobridge_: <S​id> that shouldn't be a problem, there haven't been any nouveau related commits in the rc
10:53 fdobridge_: <S​id> device_lost achieved 💪
10:54 fdobridge_: <r​edsheep> I've haven't had enough time yet to be sure it won't happen, but I have been rapidly saving and exiting over and over to try to break it the same way it did for me earlier, and I've had no issue
10:54 fdobridge_: <S​id> you could try running my api trace
10:55 fdobridge_: <S​id> or, well, replay the
10:55 fdobridge_: <S​id> or, well, replay them (edited)
10:55 fdobridge_: <r​edsheep> Yeah trying to find your old message with that now
10:56 fdobridge_: <S​id> http://cloud.sidonthe.net/d/492adfc31dde49ffbd86/
10:56 fdobridge_: <r​edsheep> Here it was
10:56 fdobridge_: <S​id> go for no-push-sync one
10:57 fdobridge_: <S​id> install the apitrace package, then run `apitrace replay /path/to/downloaded/trace`
10:57 fdobridge_: <S​id> might have to do some wine shenanigans to get it to run iirc
10:58 fdobridge_: <r​edsheep> Are you able to download back your own trace? I am hitting a security error
10:58 fdobridge_: <S​id> @asdqueerfromeu knows how to replay traces better than I do 🐸
10:58 fdobridge_: <S​id> ...ah
10:58 fdobridge_: <S​id> hang on, gimme 5 mins
10:58 fdobridge_: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1188435634642235513/image.png?ex=659a83ef&is=65880eef&hm=d760b9e3b9f26b446aceb4ad79302ec34dfdcbde9984094a2654a35e079ffdab&
10:59 fdobridge_: <r​edsheep> Yeah firefox won't even let me bypass it
11:01 fdobridge_: <S​id> am on it
11:01 fdobridge_: <r​edsheep> Should I download bottles and run the windows version of apitrace, or what? I assume this is a dx11 trace?
11:01 fdobridge_: <S​id> domain name change shenanigans
11:04 fdobridge_: <S​id> there we go, dl fixed
11:04 fdobridge_: <S​id> uh, hm... @asdqueerfromeu?
11:05 fdobridge_: <!​DodoNVK (she) 🇱🇹> How did you make the trace?
11:05 fdobridge_: <r​edsheep> Their support matrix says linux is supported but doesn't clearly define that dx11 in particular is supported on linux
11:05 fdobridge_: <S​id> followed dxvk wiki guide
11:05 fdobridge_: <S​id> but didn't disable dxvk
11:06 fdobridge_: <!​DodoNVK (she) 🇱🇹> That means it's a Direct3D trace
11:06 fdobridge_: <S​id> mhm
11:06 fdobridge_: <S​id> I'm guessing you need a wine prefix with d3dretrace.exe and dxvk installed
11:07 fdobridge_: <!​DodoNVK (she) 🇱🇹> So the person definitely needs the Windows version of apitrace
11:07 fdobridge_: <!​DodoNVK (she) 🇱🇹> With DXVK
11:07 fdobridge_: <S​id> ah
11:07 fdobridge_: <S​id> https://github.com/apitrace/apitrace
11:08 fdobridge_: <S​id> 64 bit application was traced
11:09 fdobridge_: <!​DodoNVK (she) 🇱🇹> 64-bit apitrace version should always work for replaying
11:09 fdobridge_: <S​id> from the readme: `On 64bits Linux and Windows platforms you'll need apitrace binaries that match the architecture (32bits or 64bits) of the application being traced.`
11:10 fdobridge_: <S​id> oh, wait
11:10 fdobridge_: <S​id> me dumb
11:10 fdobridge_: <S​id> right, makes sense
11:11 fdobridge_: <S​id> got win-apitrace going with lutris
11:12 fdobridge_: <S​id> https://cdn.discordapp.com/attachments/1034184951790305330/1188439000176926751/image.png?ex=659a8711&is=65881211&hm=dde3d17056b7bd0ff77171b4f51e7fc96101b73b58446cd6af00dbf0a47607da&
11:12 fdobridge_: <r​edsheep> I am just building a bottle right now with dxvk to launch the 64 bit apitrace
11:12 fdobridge_: <S​id> fair :)
11:37 fdobridge_: <r​edsheep> I like bottles a whole lot less than I did an hour ago. Am I reading the logs right where it seems to suggest that you need the executable for the application you're replaying?
11:37 fdobridge_: <S​id> nope
11:37 fdobridge_: <S​id> only need the trace
11:38 fdobridge_: <S​id> iirc
11:39 fdobridge_: <r​edsheep> That's what I thought, I was thrown by it listing the directory where the executable, but I see now the listed directory is from your computer, not mine
11:39 fdobridge_: <S​id> ah
11:42 fdobridge_: <S​id> let me try running the trace on the proprietary driver to see what happens in the meanwhile
11:52 fdobridge_: <r​edsheep> I decided bottles is the worst and replicated what you did with lutris instead, so far though that retrace shows a black screen
12:04 fdobridge_: <r​edsheep> Is that what you expected @tiredchiku? I get the feeling we have not yet gotten to the bottom of this, while lutris doesn't show device lost anywhere in terminal output it does seem something bad is happening in dmesg each time I replay that trace...
12:04 fdobridge_: <r​edsheep>
12:04 fdobridge_: <r​edsheep> ```[ 3774.323994] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:120 type:13 scope:1 part:233
12:04 fdobridge_: <r​edsheep> [ 3774.324000] nouveau 0000:01:00.0: fifo:c00000:000f:0078:[d3dretrace.exe[19294]] errored - disabling channel
12:04 fdobridge_: <r​edsheep> [ 3774.324005] nouveau 0000:01:00.0: d3dretrace.exe[19294]: channel 120 killed!
12:04 fdobridge_: <r​edsheep> [ 3859.181029] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:120 type:13 scope:1 part:233
12:04 fdobridge_: <r​edsheep> [ 3859.181036] nouveau 0000:01:00.0: fifo:c00000:000f:0078:[d3dretrace.exe[20191]] errored - disabling channel
12:04 fdobridge_: <r​edsheep> [ 3859.181042] nouveau 0000:01:00.0: d3dretrace.exe[20191]: channel 120 killed!
12:04 fdobridge_: <r​edsheep> [ 4154.290036] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:88 type:13 scope:1 part:233
12:04 fdobridge_: <r​edsheep> [ 4154.290042] nouveau 0000:01:00.0: fifo:c00000:000b:0058:[d3dretrace.exe[21059]] errored - disabling channel
12:04 fdobridge_: <r​edsheep> [ 4154.290049] nouveau 0000:01:00.0: d3dretrace.exe[21059]: channel 88 killed!```
12:06 fdobridge_: <S​id> makes sense, since when I captured the trace the game never went past a black screen
12:07 fdobridge_: <S​id> I can capture a trace again on the proprietary driver with the game loading until the main menu and we could try running that
12:07 fdobridge_: <r​edsheep> That would probably be better, I am building an unpatched rc7 kernel now to see if that stops the dmesg errors
12:08 fdobridge_: <S​id> on it :)
12:12 fdobridge_: <S​id> uploading
12:22 fdobridge_: <r​edsheep> Ok so that trace yields channel killed even without any of the 11 patches, so maybe that is just the expected result for a broken trace?
12:33 fdobridge_: <r​edsheep> I've tried downloading the new trace 4 times now, it's like the download times out. Maybe upload it in parts? I will have to test all this more later
12:45 fdobridge_: <S​id> can't split it into parts, but I'll try compressing it
12:49 fdobridge_: <S​id> hm, that didn't do much
12:50 fdobridge_: <S​id> @redsheep here: https://drive.google.com/file/d/1b4QMaQo2nAXIfPcZur98NfuRndlS_zt5/view?usp=drive_link
12:51 fdobridge_: <S​id> @redsheep here: https://drive.google.com/file/d/1b4QMaQo2nAXIfPcZur98NfuRndlS_zt5/view (edited)
12:51 fdobridge_: <S​id> @redsheep here: https://drive.google.com/file/d/1b4QMaQo2nAXIfPcZur98NfuRndlS_zt5/view (edited)
13:52 fdobridge_: <S​id> framerate is scuffed on the replay but it does work on proprietary drivers
13:59 fdobridge_: <S​id> and on nvk it hits a device lost
14:00 fdobridge_: <S​id> I'll try the other scenario in an nvidia-only environment in a bit
14:53 fdobridge_: <S​id> ok, so it's not a patchset regression because I had a device lost in nv-only env even on unpatched 6.7-rc6
15:25 fdobridge_: <!​DodoNVK (she) 🇱🇹> So the patchset didn't introduce DEVICE_LOST?
15:25 fdobridge_: <!​DodoNVK (she) 🇱🇹> I wonder if there's some NVK regression
16:26 fdobridge_: <S​id> nope, wasn't the patchset
18:38 fdobridge_: <S​id> if I have tomorrow I'll try an older version of mesa and bisect it
18:38 fdobridge_: <S​id> time tomorrow*
18:38 fdobridge_: <S​id> how far back should I check from though
20:56 fdobridge_: <r​edsheep> I wonder if were looking at multiple different bugs, I still put a ton of time into zink+NVK before the patch set and only crashed after applying them, but what you're facing sounds more like device lost was just being prevented by something else breaking first