10:44 x512[m]: How to check is GSP firmware used for Nouveau KMD?
11:11 airlied[d]: Latest versions will print a gsp version in logs
11:16 x512[m]: Latest is from which version?
11:19 chikuwad[d]: 570
11:21 x512[m]: I mean Linux kernel version.
11:37 x512[m]: Running Nouveau+NVK on RISC-V machine.
11:38 mohamexiety[d]: 6.16
11:39 x512[m]: 6.14 here :(
11:40 x512[m]: Vulkan demos have significantly lower FPS compared to x86 machine and there are no significant CPU load. suspect disabled/unsupported GSP.
11:54 karolherbst[d]: playing around more with cuda-gdb and it's certainly fun 😄
11:54 karolherbst[d]: conditional breakpoints, but you have to be aware that the register value might only update later 🙃
11:56 mohamexiety[d]: x512[m]: if this is .14 then you only have gsp 535
11:56 mohamexiety[d]: we only got 570 in 6.16, which is also when the version print thing got added
11:58 karolherbst[d]: but it's so fun...
12:29 MrBeamLodge: I sill think that tcp is vulnerable. but I do not understand if on ARM instr. set according to this site, LDR is read that is suppose to read memory of cache lines or memory location to register, dma can skip that cycle and make the transfer on it's own behalf of cpu, but i suspect this could be the case only when the memory goes to dma pci bar that cpu tries to access, if that goes to cpu pci bar region it will be done by cpu i assume,
12:29 MrBeamLodge: nic's should perform like this too and i suppose pci axi too alike https://www.nesdev.org/wiki/DMA, so the address bus can be taken over according to this article, which makes tcp vulnerable, other exploit frameworks i do not understand as to why they do so complex matters. And caches either, so when nic posts more data when it was counted, but with my algorithm maintains the checksum, it should be a matter of time or empty delay when
12:29 MrBeamLodge: register gets dma address stolen content and later it will just jump to this memory and execute arbitary code. And dma can not be easily unmapped for the os to suffer under performance loss as result.
12:49 MrBeamLodge: In my opinion since the chipsets are manufactured in united states, only vendors know how to map the cache to pcibar which is the only thing that cpu owns, memory can not be probably done by other means than dma. But caches are small compared to memory and this ain't gonna fly without my compression anyhow, technically there is no way not to use this side of dma memory loading.
18:14 Nopic: Hey list, I'm one of the unlucky owners of a GP108, I've looked around the net but the only "solution" that ever was successful was "use the proprietary driver". This can't be the only way, the card is working on older kernels (before 2.6.6. IIRC), after all?
18:18 DodoGTA: Nopic: 2.6.6 feels like a really ancient kernel
18:18 DodoGTA: Have you tried running the GPU with the latest non-LTS kernel?
18:19 Nopic: Yea, that't because I'm dumb, I meant 6.2.6 :(
18:21 Nopic: The most recent kernel I have is 6.1.0-40, while the current one (6.12.48) doesn't work anymore, IIRC the breaking change occured around the 6.2.6 release.
18:21 Nopic: It's a debian system (trixie) if that matters
18:22 DodoGTA: Nopic: What happens with the current kernel? Do you get a freeze before even reaching the tty?
18:22 Nopic: The dmesg output ends in "nouveau 0000:25:00.0: [drm] Cannot find any crtc or sizes"
18:23 Nopic: The system is working normally otherwise, it just doesn't use the card and instead it goes to the dummy terminal, I can even log into X but of course see nothing.
18:23 DodoGTA: Nopic: Can you Pastebin (or any equivalent) the full dmesg output?
18:29 Nopic: I've got the debug mode output here: https://pastebin.com/wwpzjFYJ
18:31 Nopic: The non-debug output is available too, as is the output from the currently working old kernel if that's of interest.
18:36 Mary: Nopic: the crtc error can be safely ignored but looking at the logs it seems to have probed the device just fine so that's odd...
18:36 Nopic: Workinb non-debug output is here: https://pastebin.com/Gcd18Afq
18:38 Nopic: In that one it does find a size and creates a framebuffer, that's about the only difference I can see.
18:46 Nopic: Maybe it isn't probing all outputs anymore? I don't see anything in the logs about any of that, but my display is on the DVI port, and if it only tries the HDMI it of course won't find the screen. I'd test but I have no HDMI device so I can't, but maybe there is a way to force it to use a specific output port?
18:48 Nopic: Then again, it shows the "cannot find crtc or sizes" message twice, so it seems like it does probe both ports...
18:48 Nopic: Can I somehow pass it a size to use?
23:10 Nopic: Oh well, thanks anyway, was a long shot. :)
23:13 airlied[d]: can you open a issue or find one on gitlab.freedesktop.org/drm/nouveau and attach the working debug log and not working one?
23:14 airlied[d]: I'm not sure I own a gp108, but maybe I do somewhere
23:59 Nopic: Looks like I need yet another an account for that, or am I missing something?