09:45 PaulePanter: 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:46 PaulePanter: 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:46 PaulePanter: With 256MB the kernel panics with a deadlock due to OOM situation.
09:47 PaulePanter: 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:53 karolherbst: PaulePanter: I am sure nouveau doesn't use that much memory
09:53 karolherbst: I was booting machines with <100MB memory used with nouveau loaded
09:53 PaulePanter: Hmm. I’ll try to get the logs.
09:54 PaulePanter: We have the debugging symbols in the kernel. Might this be a problem?
09:54 karolherbst: PaulePanter: but on efi systems it would be enough to use efifb or not?
09:54 karolherbst: PaulePanter: probably yes
09:54 karolherbst: debugging symbols take a lot of space
09:54 PaulePanter: -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:55 karolherbst: yeah.. debugging symbols
09:55 karolherbst: PaulePanter: strip it
09:55 karolherbst: it should be around 2M
10:08 PaulePanter: karolherbst: Thank you.
10:08 PaulePanter: For the framebuffer, should nvidiafb be sufficient too?
10:37 karolherbst: no
10:37 karolherbst: that's for really old hardware
10:41 PaulePanter: Understood. Thank you.
11:58 karolherbst: mlankhorst_: you were the one reverse engineering the voltage table back in the fermi days, weren't you?
12:03 mlankhorst_: karolherbst: yeah but lost most of it
12:04 karolherbst: 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:04 karolherbst: 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:04 karolherbst: just wondering if you know what's that all about
14:20 mlankhorst_: I forgot all details :(
14:20 mlankhorst_: sounds like something that nvidia would ignore due to overclockers
14:45 karolherbst: 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:45 karolherbst: I think this value might actually mean something else... but I also didn't spend time to actually see what it does
14:54 RSpliet: 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:55 karolherbst: probably not
14:55 karolherbst: it's more of a hint anyway
14:55 karolherbst: first thing nvidia does is to set the GPU to the highest perf level anyway
14:55 karolherbst: well
14:55 karolherbst: after starting X
15:01 RSpliet: 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:01 karolherbst: *sigh* if I run the EGL multithreaded test with valgrind, every test passes and no random crash :(
15:01 karolherbst: I get the feeling I only have _one_ race condition left
15:02 karolherbst: and it's...... somewhere
15:03 RSpliet: running valgrind with lock validation?
15:03 karolherbst: I think so
15:03 RSpliet: Tends to catch deadlock situations more than "forgotten locks"
15:03 RSpliet: but eh, it's the best you'll get :-P
15:03 karolherbst: most of the issues I was able to fix without locks
15:03 karolherbst: and I am very proud of that :p
15:04 karolherbst: I think at most there are two locks held at any time
15:04 karolherbst: and usually you have no locks at all
15:04 RSpliet: https://www.vctlabs.com/posts/2014/Jul/09/liblockdep/
15:04 RSpliet: Heh, that sounds cool
15:06 karolherbst: 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:51 pabs3: 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:02 karolherbst: pabs3: uff
16:02 karolherbst: pabs3: mind running with NV50_PROG_DEBUG=3 ?
16:02 pabs3: sure
16:03 karolherbst: not sure if it's enabled in the build
16:03 karolherbst: but hopefully that ends up printing the debug stuff
16:03 karolherbst: that would help
16:03 pabs3: hmm, doesn't seem to do anything here
16:04 pabs3: the binary has this string in it though: NV50_PROG_DEBUG_NO_COLORS
16:04 pabs3: and NOUVEAU_MESA_DEBUG
16:05 karolherbst: mhh
16:05 karolherbst: doesn't help
16:05 karolherbst: pabs3: I really want to skip trying to reproduce it myself...
16:05 karolherbst: mind doing a debug build of mesa and use that?
16:06 pabs3: after midnight here, can do tomorrow though
16:06 karolherbst: okay, cool
16:07 pabs3: what do I add to ./configure etc?
16:12 karolherbst: nothing
16:12 karolherbst: autotools doesn't exist anymore
19:35 pmoreau: 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:35 pmoreau:is still reading through the backlog)
20:14 pmoreau: Lyude, karolherbst: Has anyone been looking at https://bugs.freedesktop.org/show_bug.cgi?id=100228 and issues with 1050s?
20:15 karolherbst: uff
20:15 karolherbst: secboot issue
20:15 karolherbst: yes
20:15 karolherbst: it's a sad story overall
21:00 gnarface: pmoreau: those G96 tweaks don't fix the hardware video playback hang by any chance, do they?
21:03 gnarface: oh nevermind i'm thinking of G9
21:03 gnarface: G92*
21:03 gnarface: nevermind me
21:04 RSpliet: pabs3: https://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau/codegen?id=3e468ff2feb3fce4909ea35e7212bb99601ea816 ?