09:45PaulePanter: Hi. We want to use a crash kernel to write the memory of the crashed kernel to somewhere, so memory needs to be reserved.
09:46PaulePanter: We use 256MB, but the problem is, that we would like to have messages visible on the monitor, so on some systems with Nvidia devices we need to use Nouveau.
09:46PaulePanter: With 256MB the kernel panics with a deadlock due to OOM situation.
09:47PaulePanter: With 512M reserved it works. Is there a way to reduce the memory requirements of Nouveau? (As we only want to use the framebuffer.)
09:53karolherbst: PaulePanter: I am sure nouveau doesn't use that much memory
09:53karolherbst: I was booting machines with <100MB memory used with nouveau loaded
09:53PaulePanter: Hmm. I’ll try to get the logs.
09:54PaulePanter: We have the debugging symbols in the kernel. Might this be a problem?
09:54karolherbst: PaulePanter: but on efi systems it would be enough to use efifb or not?
09:54karolherbst: PaulePanter: probably yes
09:54karolherbst: debugging symbols take a lot of space
09:54PaulePanter: -rw-r--r-- 1 root root 182M Jul 3 15:17 /lib/modules/4.19.57.mx64.276/kernel/drivers/gpu/drm/nouveau/nouveau.ko
09:55karolherbst: yeah.. debugging symbols
09:55karolherbst: PaulePanter: strip it
09:55karolherbst: it should be around 2M
10:08PaulePanter: karolherbst: Thank you.
10:08PaulePanter: For the framebuffer, should nvidiafb be sufficient too?
10:37karolherbst: that's for really old hardware
10:41PaulePanter: Understood. Thank you.
11:58karolherbst: mlankhorst_: you were the one reverse engineering the voltage table back in the fermi days, weren't you?
12:03mlankhorst_: karolherbst: yeah but lost most of it
12:04karolherbst: mlankhorst_: yeah.. we were looking into that table and found something interested regarding this max value... I was jut wondering if you might know what's that about
12:04karolherbst: it seems that there are some GPUs out there with it being set to 0, and if we set it to something, nvidia just ignores it
12:04karolherbst: just wondering if you know what's that all about
14:20mlankhorst_: I forgot all details :(
14:20mlankhorst_: sounds like something that nvidia would ignore due to overclockers
14:45karolherbst: mlankhorst_: mhh, not quite sure... it didn't make sense that this value does anything anyway... worst case it limits the available pstates/cstates, but why put them in there in the first place?
14:45karolherbst: I think this value might actually mean something else... but I also didn't spend time to actually see what it does
14:54RSpliet: karolherbst: I think in the pstate table there was/is a variable stating the "boot perf lvl". The blob sets the card back to that level upon unloading. Have you considered this unknown value could be the voltage-equivalent?
14:55karolherbst: probably not
14:55karolherbst: it's more of a hint anyway
14:55karolherbst: first thing nvidia does is to set the GPU to the highest perf level anyway
14:55karolherbst: after starting X
15:01RSpliet: Yep, clocking back on unload is a protection mechanism preventing your card from overheating while the blob isn't there to monitor its temperature and act accordingly ;-)
15:01karolherbst: *sigh* if I run the EGL multithreaded test with valgrind, every test passes and no random crash :(
15:01karolherbst: I get the feeling I only have _one_ race condition left
15:02karolherbst: and it's...... somewhere
15:03RSpliet: running valgrind with lock validation?
15:03karolherbst: I think so
15:03RSpliet: Tends to catch deadlock situations more than "forgotten locks"
15:03RSpliet: but eh, it's the best you'll get :-P
15:03karolherbst: most of the issues I was able to fix without locks
15:03karolherbst: and I am very proud of that :p
15:04karolherbst: I think at most there are two locks held at any time
15:04karolherbst: and usually you have no locks at all
15:04RSpliet: Heh, that sounds cool
15:06karolherbst: yeah... per context pushbuf and fence list.. although I want to move the fence list back into the screen, which I think we have to do... but I currently have no proper idea on how to do that with only atomics
15:51pabs3: mesa 19.1.2-1 (Debian) seems to cause crashes in vlc under nouveau whenever it tries to play a video, any thoughts? https://paste.debian.net/hidden/3a5cd022/
16:02karolherbst: pabs3: uff
16:02karolherbst: pabs3: mind running with NV50_PROG_DEBUG=3 ?
16:03karolherbst: not sure if it's enabled in the build
16:03karolherbst: but hopefully that ends up printing the debug stuff
16:03karolherbst: that would help
16:03pabs3: hmm, doesn't seem to do anything here
16:04pabs3: the binary has this string in it though: NV50_PROG_DEBUG_NO_COLORS
16:04pabs3: and NOUVEAU_MESA_DEBUG
16:05karolherbst: doesn't help
16:05karolherbst: pabs3: I really want to skip trying to reproduce it myself...
16:05karolherbst: mind doing a debug build of mesa and use that?
16:06pabs3: after midnight here, can do tomorrow though
16:06karolherbst: okay, cool
16:07pabs3: what do I add to ./configure etc?
16:12karolherbst: autotools doesn't exist anymore
19:35pmoreau: RSpliet: I did some tweaks on the G96, as there was a mismatch on the size of PCIe tags leading to a hang of that GPU.
19:35pmoreau:is still reading through the backlog)
20:14pmoreau: Lyude, karolherbst: Has anyone been looking at https://bugs.freedesktop.org/show_bug.cgi?id=100228 and issues with 1050s?
20:15karolherbst: secboot issue
20:15karolherbst: it's a sad story overall
21:00gnarface: pmoreau: those G96 tweaks don't fix the hardware video playback hang by any chance, do they?
21:03gnarface: oh nevermind i'm thinking of G9
21:03gnarface: nevermind me
21:04RSpliet: pabs3: https://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau/codegen?id=3e468ff2feb3fce4909ea35e7212bb99601ea816 ?