00:13 iankelling: I posted to the nouveau list earlier today, subject "Any tips to avoid Nouveau crashes & freezes?" https://lists.freedesktop.org/archives/nouveau/2023-March/041950.html , if anyone here has any tips, please let me know
01:03 pabs: my experience: with some old hardware, the libre firmware generated by nouveau at runtime can sometimes cause freezes in some situations (for eg mpv on gnome on Debian bullseye can trigger it), installing the proprietary firmware from the ancient proprietary drivers can fix that.
01:04 Lyude: airlied: did we just get GSP firmware loading?
12:27 fdobridge: <k​arolherbst🐧🦀> @airlied how do I even now that gsp is loaded?
12:55 fdobridge: <E​sdras Tarsis> if the message "pmu: firmware unavailable" does not appear in dmesg, GSP has been loaded iirc
13:33 fdobridge: <🌺​ ¿butterflies? 🌸> what's the state of nouveau on t194 by the way
14:48 fdobridge: <k​arolherbst🐧🦀> yeah well, it did, and I have no clue what I've done wrong
16:34 fdobridge: <M​ohamexiety> so how do I run the script?
16:34 fdobridge: <M​ohamexiety> > sed: can't read version.mk: No such file or directory
18:08 fdobridge: <E​sdras Tarsis> You need to run inside the openrm source code directory
18:31 fdobridge: <E​sdras Tarsis> did you put all the gsp firmware with the correct names in the initramfs?
18:31 fdobridge: <k​arolherbst🐧🦀> no idea 🙂
18:31 fdobridge: <k​arolherbst🐧🦀> I wished the driver would just tell me
18:31 fdobridge: <k​arolherbst🐧🦀> don't really want to waste time playing a guessing game here
18:37 fdobridge: <M​ohamexiety> Alright, thanks!
18:37 fdobridge: <M​ohamexiety> Do you know how to get the firmware/booters from the NV prop driver? I shouldn't have to install it, right?
18:42 fdobridge: <a​irlied> @karolherbst🐧patches welcome, as I said this isn't meant for general consumption yet, if you try it and it breaks you keep the pieces
18:42 fdobridge: <a​irlied> There is a trace option you can use but I don't have it in front of me
18:45 fdobridge: <a​irlied> debug=trace
18:45 fdobridge: <E​sdras Tarsis> I don't know if the proprietary driver provides these firmwares to the user, I just used the ones from openrm
18:45 fdobridge: <M​ohamexiety> Oh
18:45 fdobridge: <M​ohamexiety> I see
19:13 fdobridge: <E​sdras Tarsis> You can see the firmware name in `nvkm_debug(subdev, "firmware \"%s\" unavailable\n", f);` in the nvkm_firmware_get function, you can change nvkm_debug to nvkm_warn so it will appear on dmesg
19:14 fdobridge: <E​sdras Tarsis> but basically you need these firmwares:
19:14 fdobridge: <E​sdras Tarsis> ```
19:14 fdobridge: <E​sdras Tarsis> [~] $ ls /lib/firmware/nvidia/tu117/gsp
19:14 fdobridge: <E​sdras Tarsis> booter_load-5258902.bin booter_unload-5258902.bin bootloader-5258902.bin gsp-5258902.bin
19:14 fdobridge: <E​sdras Tarsis> ```
19:14 fdobridge: <k​arolherbst🐧🦀> ohh.. somehow I missed that line
19:14 fdobridge: <k​arolherbst🐧🦀> that shouldn't be a nouveau specific debug thing though
19:20 fdobridge: <M​ohamexiety> does the script get stuck on
19:20 fdobridge: <M​ohamexiety> > Creating nvidia/ad102/gsp/bootloader-5258902.bin
19:20 fdobridge: <M​ohamexiety> for anyone else?
19:21 fdobridge: <M​ohamexiety> I can get all the firmware except for `gsp-5258902.bin`
19:21 fdobridge: <E​sdras Tarsis> the gsp you can get from the nv prop driver
19:22 fdobridge: <M​ohamexiety> ah
19:22 fdobridge: <M​ohamexiety> I see I see, sorry
19:23 fdobridge: <E​sdras Tarsis> I think TimurTabi can help you
19:23 fdobridge: <M​ohamexiety> nah it's fine
19:23 fdobridge: <M​ohamexiety> I got all the ga102 binaries except for the gsp one. but since I can get that from the prop driver then it's not an issue
19:26 fdobridge: <E​sdras Tarsis> yes, just extract the .run, the firmware will be in the firmware directory
19:32 fdobridge: <M​ohamexiety> well this is problematic 😮
19:32 fdobridge: <M​ohamexiety> https://cdn.discordapp.com/attachments/1034184951790305330/1084559593209876530/Screenshot_20230312_213227.png
19:34 fdobridge: <E​sdras Tarsis> gsp_tu10x is for turing, gsp_ad10x is for ampere and ada
19:35 fdobridge: <M​ohamexiety> hm I see. thought the ampere one was missing. thanks!
19:35 fdobridge: <M​ohamexiety> so do I take it as is and rename it to gsp-5258902.bin, then place it in lib/firmware/nvidia/ga102/gsp?
19:36 fdobridge: <E​sdras Tarsis> oh wait
19:36 fdobridge: <M​ohamexiety> or just place it as it is?
19:36 fdobridge: <🌺​ ¿butterflies? 🌸> more nuanced
19:36 fdobridge: <🌺​ ¿butterflies? 🌸> also they reshuffled the FWs again
19:37 fdobridge: <M​ohamexiety> how so?
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> ``` switch (fw_chip_family)
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> {
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_AD10X: // fall through
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GA10X:
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> return NV_FIRMWARE_PATH_FOR_FILENAME("gsp_ga10x.bin");
19:37 fdobridge: <🌺​ ¿butterflies? 🌸>
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GH100: // fall through
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GA100: // fall through
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_TU11X: // fall through
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_TU10X:
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> return NV_FIRMWARE_PATH_FOR_FILENAME("gsp_tu10x.bin");
19:37 fdobridge: <🌺​ ¿butterflies? 🌸>
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_END: // fall through
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_NULL:
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> return "";
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> }
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> ```
19:37 fdobridge: <🌺​ ¿butterflies? 🌸> on r530
19:37 fdobridge: <E​sdras Tarsis> @Mohamexiety on 525.89.02 gsp_ad10x is for ada only
19:37 fdobridge: <M​ohamexiety> huh, this is odd
19:37 fdobridge: <E​sdras Tarsis> https://github.com/NVIDIA/open-gpu-kernel-modules/blob/e598191e8e559df8fe54eaa79b2e3cca6dfdbca8/kernel-open/common/inc/nv-firmware.h#L84
19:38 fdobridge: <E​sdras Tarsis> for ampere and turing you need gsp_tu10x
19:38 fdobridge: <M​ohamexiety> so given this, I should use the turing one
19:38 fdobridge: <M​ohamexiety> yep, thanks!
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> 525 was
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> ``` switch (fw_chip_family)
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> {
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_AD10X: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GA10X:
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> return NV_FIRMWARE_PATH_FOR_FILENAME("gsp_ga10x.bin");
19:38 fdobridge: <🌺​ ¿butterflies? 🌸>
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GH100: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GA100: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_TU11X: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_TU10X:
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> return NV_FIRMWARE_PATH_FOR_FILENAME("gsp_tu10x.bin");
19:38 fdobridge: <🌺​ ¿butterflies? 🌸>
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_END: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_NULL:
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> return "";
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> }
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> ```
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> ugh
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> ``` switch (fw_chip_family)
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> {
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_AD10X:
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> return NV_FIRMWARE_PATH_FOR_FILENAME("gsp_ad10x.bin");
19:38 fdobridge: <🌺​ ¿butterflies? 🌸>
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GH100: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GA100: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_GA10X: // fall through
19:38 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_TU11X: // fall through
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_TU10X:
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> return NV_FIRMWARE_PATH_FOR_FILENAME("gsp_tu10x.bin");
19:39 fdobridge: <🌺​ ¿butterflies? 🌸>
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_END: // fall through
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> case NV_FIRMWARE_CHIP_FAMILY_NULL:
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> return "";
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> }```
19:39 fdobridge: <🌺​ ¿butterflies? 🌸> this
19:39 fdobridge: <M​ohamexiety> yeah. it's weird tbh
19:39 fdobridge: <E​sdras Tarsis> yeah, this is what my link shows
19:39 fdobridge: <M​ohamexiety> I'd think AMpere and Ada are closer to each other... and 530 matches this
19:39 fdobridge: <M​ohamexiety> but I guess they're still working on things
19:39 fdobridge: <E​sdras Tarsis> yes, and they need to implement a stable ABI
19:40 fdobridge: <🌺​ ¿butterflies? 🌸> things aren't _remotely_ ready for that.
19:40 fdobridge: <M​ohamexiety> yeah this is really a bit janky
19:40 fdobridge: <🌺​ ¿butterflies? 🌸> not happening soon
19:40 fdobridge: <E​sdras Tarsis> ik
19:41 fdobridge: <M​ohamexiety> how early is it? given that the GSP is validated for DC use (i.e., critical / stable environment) I thought things were mostly ready.
19:41 fdobridge: <🌺​ ¿butterflies? 🌸> the ABI is not stable
19:41 fdobridge: <🌺​ ¿butterflies? 🌸> or rather
19:41 fdobridge: <🌺​ ¿butterflies? 🌸> NV always does coordinated FW + KM + UM releases
19:41 fdobridge: <🌺​ ¿butterflies? 🌸> so ABI stability _just doesn't matter_ for their drv stack
19:41 fdobridge: <M​ohamexiety> ah got you now
19:43 fdobridge: <a​irlied> DC use is very feature limited as well
19:43 fdobridge: <a​irlied> No displays. No suspend resume, little power mgmt
19:44 fdobridge: <M​ohamexiety> so last question, sorry, do I just take the tu .bin file as is and plop it into the lib/firmware/... file? or do I need to do anything to it?
19:44 fdobridge: <E​sdras Tarsis> you need to rename to gsp-5258902.bin and add all the firmwares to your initramfs
19:56 fdobridge: <g​ouz> is there any documentation on how to try out loading the gsp?
19:58 fdobridge: <a​irlied> No
19:58 fdobridge: <a​irlied> This backscroll is it,
20:01 fdobridge: <M​ohamexiety> really sorry for this but do you know how to add the firmware to the initramfs? I tried `dracut -f` (fedora here) but it doesn't seem to have added it when looking with `lsinitrd`:
20:01 fdobridge: <M​ohamexiety> ```
20:01 fdobridge: <M​ohamexiety> drwxr-xr-x 1 root root 0 Nov 16 20:00 usr/lib/firmware/nvidia
20:01 fdobridge: <M​ohamexiety> drwxr-xr-x 1 root root 0 Nov 16 20:00 usr/lib/firmware/nvidia/ga102
20:01 fdobridge: <M​ohamexiety> drwxr-xr-x 1 root root 0 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/acr
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 33908 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/acr/ucode_ahesasc.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 16052 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/acr/ucode_asb.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 13784 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/acr/ucode_unload.bin.xz
20:01 fdobridge: <M​ohamexiety> drwxr-xr-x 1 root root 0 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/gr
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 348 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/gr/fecs_bl.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 1684 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/gr/fecs_sig.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 348 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/gr/gpccs_bl.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 1684 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/gr/gpccs_sig.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 67720 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/gr/NET_img.bin.xz
20:01 fdobridge: <M​ohamexiety> drwxr-xr-x 1 root root 0 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/nvdec
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 7004 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/nvdec/scrubber.bin.xz
20:01 fdobridge: <M​ohamexiety> drwxr-xr-x 1 root root 0 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/sec2
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 180 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/sec2/desc.bin.xz
20:01 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 508 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/sec2/hs_bl_sig.bin.xz
20:02 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 99644 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/sec2/image.bin.xz
20:02 fdobridge: <M​ohamexiety> -rw-r--r-- 1 root root 1704 Nov 16 20:00 usr/lib/firmware/nvidia/ga102/sec2/sig.bin.xz
20:02 fdobridge: <M​ohamexiety> ```
20:02 fdobridge: <a​irlied> I only load nouveau after boot
20:02 fdobridge: <k​arolherbst🐧🦀> @airlied mhh.. were declarations for the new firmware files added?
20:03 fdobridge: <a​irlied> No
20:03 fdobridge: <k​arolherbst🐧🦀> yeah, then initramfs won't work
20:03 fdobridge: <M​ohamexiety> that's actually probably a better approach for now given the boot hanging I used to see before
20:04 fdobridge: <a​irlied> Also nvk won't work
20:05 fdobridge: <k​arolherbst🐧🦀> will opengl work?
20:06 fdobridge: <k​arolherbst🐧🦀> which would be interesting, becuase I don't see why nvk wouldn't, but nvk would
20:06 fdobridge: <a​irlied> Yes GL works
20:07 fdobridge: <k​arolherbst🐧🦀> ohh, is it because of the sw channel hack?
20:07 fdobridge: <k​arolherbst🐧🦀> we shouldn't probably drop it and tell people to move to the new kernel hack
20:07 fdobridge: <a​irlied> Syncobjs don't work
20:07 fdobridge: <a​irlied> And the sw hack
20:07 fdobridge: <k​arolherbst🐧🦀> well.. syncobjs don't matter, right?
20:07 fdobridge: <k​arolherbst🐧🦀> we don't use them today anyway
20:07 fdobridge: <a​irlied> For nvk they do
20:08 fdobridge: <k​arolherbst🐧🦀> since when are we using syncobjs?
20:08 fdobridge: <a​irlied> Fence waits don't work
20:08 fdobridge: <k​arolherbst🐧🦀> ahh...
20:08 fdobridge: <a​irlied> So even fake syncobjs are busted
20:08 fdobridge: <k​arolherbst🐧🦀> kind of glad I didn't merge bo waits yet for gl
20:09 fdobridge: <a​irlied> If you want to jump through a hoop there is a patch in a nouvelles branch that can help
20:09 fdobridge: <k​arolherbst🐧🦀> yeah.. though at least I don't need nvk to replace that sw hack
20:10 fdobridge: <k​arolherbst🐧🦀> hopefully I'll work out how that priv access stuff works next week
20:10 fdobridge: <E​sdras Tarsis> idk, I'm using mkinitcpio (Arch Linux)
20:10 fdobridge: <M​ohamexiety> would that hoop make nvk work? I am basically doing all this just to be able to load nvk since the normal FW hangs
20:10 fdobridge: <k​arolherbst🐧🦀> @airlied but anyway, we'll probably need some way to indicate to userspace that GSP is used
20:10 fdobridge: <k​arolherbst🐧🦀> I'm like 80% confident that we'll require it
20:10 fdobridge: <a​irlied> There are going to be a bunch of things needed before any of this is polished enough
20:11 fdobridge: <E​sdras Tarsis> initramfs is working for me
20:11 fdobridge: <k​arolherbst🐧🦀> you can force add files in dracut
20:12 fdobridge: <k​arolherbst🐧🦀> @Mohamexiety ^^ but I'd have to look it up myself as well
20:12 fdobridge: <k​arolherbst🐧🦀> but you can declare some config and list those files
20:12 fdobridge: <a​irlied> Actually I can't find the patch, not sure where I left it
20:12 fdobridge: <M​ohamexiety> yeah I'll see if I can find anything. thanks!
20:14 fdobridge: <M​ohamexiety> I guess I could also try loading nouveau after booting. how would I do that?
20:17 fdobridge: <a​irlied> @karolherbst🐧can you see a nouveau-gsprm-nonstall branch in nouvelles/kernel?
20:19 fdobridge: <a​irlied> Ah it is there, that has the main fence wait fix wip
20:19 fdobridge: <a​irlied> Two patches
21:17 fdobridge: <k​arolherbst🐧🦀> okay cool, will check it out tomorrow then
23:14 bylaws: Hi, I was wondering when NVC0_HW_QUERY_TFB_BUFFER_OFFSET gets reset?
23:14 bylaws: There's no explicit clear register for it
23:43 fdobridge: <a​irlied> it's not a register afaik