11:02 casejuarez: hello! I am experiencing live image corruption on an NV160 card, main docs recommend raising the card's performance mode, I was wondering if anyone here knows any other workaround? the card is RTX A1000 (10de:25b9)
12:35 karolherbst: casejuarez: what kind of corruption?
12:41 casejuarez: karolherbst: horizontal tearing artifacts, here is a video of how that looks: https://litter.catbox.moe/4a4uto.mp4
12:41 karolherbst: huh...
12:43 karolherbst: casejuarez: sure that the RTX A1000 is driving the display? Usually on laptops that's not the case
12:51 casejuarez: karolherbst: I am not sure, I checked lspci -k and this seems to be the only GPU (no integrated gpu?) there is a VGA controller and its i915, but x11 and the kernel are loading nouveau
12:51 karolherbst: huh.. strange
12:53 karolherbst: well.. X and the kernel would load both anyway, but it's more of a question what drives the internel display.. or well, what renders to it
12:53 karolherbst: could be that your setup causes the desktop to be rendered on the nvidia GPU (which doesn't support OpenGL yet anyway) and copies it over to the intel one...
12:53 karolherbst: mind sharing your Xorg log?
12:53 karolherbst: and dmesg
12:54 karolherbst: anyway.. that _might_ explain those artifacts
12:54 casejuarez: sure thing, let me get a copy of those one sec.
13:19 casejuarez: karolherbst: xorg.log (https://paste.mozilla.org/nC6SYfqK) and dmesg output (https://paste.mozilla.org/dpiQhAxa)
13:21 karolherbst: strange...
13:21 karolherbst: so it's indeed as I assumed it would be
13:21 karolherbst: yeah.. that's going to suck in terms of battery life time :)
13:22 karolherbst: mhh actually...
13:22 karolherbst: (II) modeset(0): using drv /dev/dri/card0
13:22 karolherbst: (II) modeset(G0): using drv /dev/dri/card1
13:23 karolherbst: card0 _should_ be the intel one though
13:23 karolherbst: but.. "Refusing to try glamor on llvmpipe"
13:24 karolherbst: casejuarez: ohh wait.. that's on qubes?
13:25 karolherbst: the nvidia GPU crashed anyway, so I doubt it's doing anything at all
13:25 karolherbst: okay.. now it makes all sense
13:27 karolherbst: casejuarez: I suspect that due to software rendering something doesn't flush correctly and that's a qubes bug in the end
15:25 casejuarez: karolherbst: I will try a different distro and report back, I still suspect this is related to kernel <-> nouveau <-> GPU interaction but worth trying in another setup
15:26 karolherbst: yeah.. well.. the nvidia GPU does crash and I suspect it's not even used based on the dmesg you shared
15:26 karolherbst: but not having acceleration in X can cause such issues if you copy window contents around and stuff
15:32 karolherbst: cwabbott: but I am actually surprised that all acceleration is disabled, I was hoping that quebes at least enables it on the X server side
15:33 karolherbst: which they really should, because not enabling it, is strictly not supported for quebes use case afaik
21:39 TimurTabi: Does anyone know what "bootfb" is? I see references to it in the kernel, but not a clear explanation of what it is.
21:42 airlied: TimurTabi: got a ptr to a reference?
21:43 TimurTabi: No, just some kind of internal bug report that blames it for some kind of failure. It appears to be created by sysfb_simplefb.c. I've seen a few posts here and there that suggest it does tend to interfere with other drivers, but I can't find any docs that give specific instructions.
21:44 TimurTabi: It seems like GPU drivers are supposed to release the bootfb memory?
21:45 karolherbst: huh?
21:45 karolherbst: well.. in the end it's memory setup by the vbios, so the driver has to take control over it
21:45 airlied: TimurTabi: I'm not seeing many references to it in hte upstream kernel
21:45 TimurTabi: Same here.
21:45 airlied: at BOOTFB is named once
21:46 karolherbst: I suspect it's the fb set up by the firmware :P
21:46 airlied: so to remove that you have to use the aperture conflict apis
21:47 TimurTabi: I'm not familiar with those
21:47 airlied: which change a lot over time
21:47 karolherbst: nouveau does use those
21:47 airlied: in latest Linus kernel include/linux/aperture.h
21:49 airlied: TimurTabi: if you use those the driver has to register it's own fbcon then
21:49 airlied: which I believe the out-of-tree doesn't
21:49 TimurTabi: This sounds like something that's been around a while?
21:50 airlied: it used to be part of drm
21:50 TimurTabi: Is this something that changed around 5.15?
21:51 airlied: drm_aperture_remove_conflicting_framebuffers
21:51 airlied: not sure when simplefb came about either
21:51 airlied: but 5.15 would be around that time
21:52 airlied: 11e8f5fd223bd4d33fa10527bad3fe48469a15df drm: Add simpledrm driver