05:15pmoreau: I can use my computer with Nouveau again, without the screens turning into a Christmas tree, yay!! A big thanks to everyone involved!
05:16pmoreau: I’ll be looking into the Blender issue that was reported recently. I tried it this morning on my GP104, and it doesn’t crash for me but the screen freezes instead.
05:19karolherbst: pmoreau: uff.. I guess we do something stupid in mesa then
05:20karolherbst: maybe multi threading issue?
05:21pmoreau: Maybe? I’ll dig deeper into it tonight; I built a debug version of Mesa so that I can step through it while running Blender.
05:21pmoreau: I’ll also build the latest Nouveau kernel version, and set up SSH to see what’s actually happening when it freezes.
05:23karolherbst:really should continue working on the mt fixes. It's nearly done, just missing some random bits and memory corruptions
05:23karolherbst: the biggest issue right now we have is that we attach buffers to pushbuffers we replace later (the buffers) so on kick the pushbuffer keep references to already fred buffers and things just go south
05:24karolherbst: and super annoying to find the cause
05:25pmoreau: Is https://github.com/karolherbst/mesa/tree/mt_fixes_take2 the latest? I could try that out and see whether it helps.
05:27karolherbst: yeah it is, but it has some serious regression in some mt cases which I still have to track down
05:27karolherbst: but it fixes a bunch of other stuff
05:27pmoreau: Okay, so still worth testing?
05:31karolherbst: pmoreau: last time I looked into that with imirkin, he came up with such a patch: https://gitlab.freedesktop.org/mesa/mesa/commit/d1d2bb8c07d1e20d654f558ea4750aeb09d34ff9
05:31karolherbst: and I expect we might need a couple more of those
05:33pmoreau: I see
05:34karolherbst: we actually hit this inside chromium :)
05:34karolherbst: it had like 100 opengl contexts open
05:34karolherbst: so this was fun
05:34pmoreau: :-) But was that the cause of the black boxes?
05:34pmoreau: 100 OpenGL contexts opened O_O
05:35karolherbst: I don't think so
05:35karolherbst: webgl cts
05:35karolherbst: I think with my branch I am able to run through the entire cts without anything weird happening :D
07:43pmoreau: sravn: Dunno if you saw, but your patches are part of the Nouveau pull request for 5.3, sent this morning. :-)
08:05sravn: pmoreau: Thanks, I look forward to end the journey to kill all uses of drmP.h
08:15karolherbst: ui... my jetson might arrive tomorrow :)
09:43pabs3: karolherbst: I got another TRAP hang (hadn't setup killing yet so rebooted), is SIGTERM enough or do I need SIGKILL?
09:57karolherbst: SIGKILL I thikn
09:57karolherbst: you can try sigterm though
14:03zwol: Hi I need help troubleshooting appalling display flicker in a dual-head configuration with nouveau. Only one head is affected, and it's affected from the moment nouveaufb activates.
14:06zwol: Both monitors are running at their native resolution. The flickering one is a Dell 2408WFP (max res email@example.comHz) connected via DVI; the not-flickering one is a Dell G4210 (max res firstname.lastname@example.org) connected via HDMI.
14:06gnarface: zwol: are either of them using adapters?
14:07gnarface: i had this problem with a cheap analog vga to dvi adapter
14:07gnarface: but it also showed up as a kernel bug before, seemingly unrelated to the adapter
14:07zwol: No cable adapters. The HDMI cable is HDMI at one end and DVI at the other, but that's the monitor that _doesn't_ have a problem.
14:08gnarface: in the latter case it was related to some mistake in the EDID checking but there's some kernel command-line parameter you can use to suppress it
14:09zwol: hm I don't see the string "edid" in dmesg
14:10zwol: trying to find where gdm has hidden xorg.log this month
14:10gnarface: maybe ~/.local/share/xorg?
14:12zwol: ah yes here we are
14:13zwol: gnarface: https://pastebin.com/Bmq0tmsJ
14:14zwol: hm I just noticed a possible configuration problem, but I gotta log out and back in to fix it, brb
14:20gnarface: zwol: found it: drm_kms_helper poll=0
14:21gnarface: i have it as "options drm_kms_helper poll=0" in a module options config file, but it could in theory be added to the kernel command-line too, i think as drm_kms_helper.poll=0 ?
14:21gnarface: something like that
14:22gnarface: anyway the type of flickering was indistinguishable from having a cheapo DVI adapter that didn't pass all the pins through
14:22gnarface: it was definitely also a dual-head system
14:22gnarface: but no HDMI was involved (a much older card)
14:22zwol: so I'm looking at the EDID dumps in the xorg.log I pastebinned and I don't think EDID is the problem
14:23gnarface: even with a good adapter, the bug eventually reappeared in a later update, so i just stopped commenting this option out
14:23gnarface: i'm not sure if it looked like edid was any apparent problem on my end either
14:23zwol: well I can give your suggestion a try but I'll have to reboot again
14:23gnarface: i ended up assuming that a key factor was the 50' analog vga cable i was using for that display
14:23zwol: really should've brought my laptop to work today :)
14:24gnarface: echo N> /sys/module/drm_kms_helper/parameters/poll
14:24gnarface: askubuntu.com suggests this might work to change it without rebooting^
14:24zwol: giving myself access to /dev/fbXX didn't change a thing, in case that (EE) in xorg.log distracts you as well
14:25gnarface: /dev/fbX i think is for framebuffer drivers.
14:25gnarface: i'm aware it trys a bunch of drivers at once to find out what sticks
14:25gnarface: just make sure it settles on the nouveau one, or manually specify it
14:25zwol: it definitely does settle on nouveau
14:28zwol: changing the poll parameter with the computer running didn't help
14:28gnarface: hmmm, drat.
14:28zwol: i will now see if setting it on the kernel command line does help
14:30zwol: nope, no change
14:32gnarface: i'm out of ideas then
14:33gnarface: if you've tried specifying manufacturer spec horizontal and vertical refresh ranges manually in the xorg.conf too and that still doesn't work, i've got nothing.
14:33zwol: hm i haven't tried that yet
14:33zwol: is there a current guide for doing that you could point me at? i haven't had to do that in years
14:34zwol: xrandr _says_ the displays are running at what I believe to be their native resolutions and refresh rates, though
14:34gnarface: if it does, then they probably actually are
14:35gnarface: the way to do it in xorg.conf hasn't changed, all that has changed is you don't need the entire config anymore
14:35gnarface: most distros should ship with a manpage for xorg.conf and for the nouveau driver
14:35gnarface: so, it's something to try
14:35gnarface: but it might be futile
14:36zwol: i'm inclined to think this is a problem at the kernel level since the flickering is visible in a text console too
14:37zwol: and also manifests in graphical plymouth and wayland
14:37gnarface: oh? yea, that's interesting
14:37gnarface: i'm starting to still suspect the cable or the connection somehow too though
14:38zwol: frankly I suspect the monitor itself, which is old and has been having other problems
14:38zwol: the counter-argument is that it was fine with the nvidia binary driver
14:38gnarface: i don't think the console even uses the nouveau driver, it would be modesetting probably.
14:38gnarface: hrmmm.....i could be wrong though
14:38gnarface: do you have nomodeset in your grub boot parameters?
14:39zwol: the opposite
14:39gnarface: oh so it is loading the modesetting driver before it gets to nouveau?
14:39gnarface: hmmm. i wonder if that is the issue.
14:39zwol: i think
14:39gnarface: that's something else that's easy to test
14:39gnarface: but would also need a reboot
14:40zwol: `/etc/default/grub` has: GRUB_GFXMODE=1920x1080x32 GRUB_GFXPAYLOAD_LINUX=keep GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
14:40zwol: `/etc/initramfs-tools/modules` has: drm \n nouveau modeset=1
14:40zwol: (this is Debian unstable)
14:40gnarface: ah, maybe it is a new feature then
14:41gnarface: "quiet" will suppress a lot of messages during bootup even without "splash"
14:41zwol: how can I check whether the modesetting driver is loaded?
14:41zwol: i'm actually not sure anymore
14:41gnarface: lsmod should show it
14:41gnarface: i thihnk it's called "kms"
14:41zwol: ah, in that case: no, it isn't loaded
14:42gnarface: so nouveau must be handling it
14:42zwol: i'm going to try turning off graphical grub and splash and so on
14:42gnarface: i would try without specifying GFXMODE and without "quiet splash" and just set "nomodeset" and see if that fixes the flickering.
14:42gnarface: i dunno if you need to remove modeset=1 from the nouveau driver load line though
14:43gnarface: and judging by where that is, i'm not even sure the change would take unless you regenerate the initrd.img
14:43zwol: rebooting, brb
14:56zwol: gnarface: with graphical boot disabled, and "nomodeset" on the command line, the problem monitor doesn't even turn on and also X won't start
14:57zwol: gnarface: with graphical boot disabled and nothing on the kernel command line, the problem monitor turns on as soon as nouveaufb loads, and the flicker starts immediately
14:57zwol: gnarface: so then i thought about what you said about cables and i decided to try swapping which cable goes to which monitor
14:58zwol: gnarface: and that completely cured it (well, i haven't tried turning grub gfxmode / plymouth back on, but this computer normally runs 24x7, I may just not bother)
14:59zwol: gnarface: i don't understand _why_ this fixed it but frankly i need to get back to work :)
15:09gnarface: zwol: i don't get it either, but one of the actual nouveau developers probably might have some guesses. my best guess is just that cables sometimes go bad. it's pretty rare but i'm old enough now that i've seen it happen more than once.
15:10gnarface: and i've seen situations where cables aren't completely bad, they're just bad enough to cause disruption for certain drivers/software but not others
15:18gnarface: HDMI is definitely plagued me more than other connection types in this regard though; the cheap HDMI cables are never worth it
17:39Lyude: btw, it looks like some of the MST+nouveau related patches I sent out last night are being held back from the nouveau ML because of too many receipients, could someone approve them so they go through?
18:26pmoreau: Lyude: Sending useful patches to people, what were you thinking of! :-D
18:27pmoreau: IIRC some discussion not too long ago, only marcheu (and maybe skeggsb?) can let the messages go through.
18:36ajax: marcheu is the only admin for nouveau@
18:36ajax: but there are also sitewide mailman admins, myself among them
18:36ajax: i've cleared the mod queue
18:41pmoreau: Thanks ajax!
18:42pmoreau: Who should we ask for adding a few active Nouveau developers as admin for the list?
18:44ajax: i can do that, i believe
18:45ajax: assuming marcheu is okay with it, of course
18:48pmoreau: Of course
19:08marcheu: yeah please add more, I moderate when I have time but not constantly
19:18karolherbst: ajax: I think it makes sense to add skeggsb, ilia and me. Maybe pmoreau if he is fine with it as well
19:19pmoreau: I agree with Karol, with adding skeggsb, imirkin and him. I’m fine with being on the list as well.
19:21karolherbst: rhyskidd: do you know if the benchmark in deus ex md had rendering issues with nouveau?
19:21karolherbst: was trying it today and it was little borked
19:21karolherbst: some flickering