11:02casejuarez: 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:35karolherbst: casejuarez: what kind of corruption?
12:41casejuarez: karolherbst: horizontal tearing artifacts, here is a video of how that looks: https://litter.catbox.moe/4a4uto.mp4
12:41karolherbst: huh...
12:43karolherbst: casejuarez: sure that the RTX A1000 is driving the display? Usually on laptops that's not the case
12:51casejuarez: 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:51karolherbst: huh.. strange
12:53karolherbst: 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:53karolherbst: 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:53karolherbst: mind sharing your Xorg log?
12:53karolherbst: and dmesg
12:54karolherbst: anyway.. that _might_ explain those artifacts
12:54casejuarez: sure thing, let me get a copy of those one sec.
13:19casejuarez: karolherbst: xorg.log (https://paste.mozilla.org/nC6SYfqK) and dmesg output (https://paste.mozilla.org/dpiQhAxa)
13:21karolherbst: strange...
13:21karolherbst: so it's indeed as I assumed it would be
13:21karolherbst: yeah.. that's going to suck in terms of battery life time :)
13:22karolherbst: mhh actually...
13:22karolherbst: (II) modeset(0): using drv /dev/dri/card0
13:22karolherbst: (II) modeset(G0): using drv /dev/dri/card1
13:23karolherbst: card0 _should_ be the intel one though
13:23karolherbst: but.. "Refusing to try glamor on llvmpipe"
13:24karolherbst: casejuarez: ohh wait.. that's on qubes?
13:25karolherbst: the nvidia GPU crashed anyway, so I doubt it's doing anything at all
13:25karolherbst: okay.. now it makes all sense
13:27karolherbst: casejuarez: I suspect that due to software rendering something doesn't flush correctly and that's a qubes bug in the end
15:25casejuarez: 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:26karolherbst: yeah.. well.. the nvidia GPU does crash and I suspect it's not even used based on the dmesg you shared
15:26karolherbst: but not having acceleration in X can cause such issues if you copy window contents around and stuff
15:32karolherbst: 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:33karolherbst: which they really should, because not enabling it, is strictly not supported for quebes use case afaik
21:39TimurTabi: Does anyone know what "bootfb" is? I see references to it in the kernel, but not a clear explanation of what it is.
21:42airlied: TimurTabi: got a ptr to a reference?
21:43TimurTabi: 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:44TimurTabi: It seems like GPU drivers are supposed to release the bootfb memory?
21:45karolherbst: huh?
21:45karolherbst: well.. in the end it's memory setup by the vbios, so the driver has to take control over it
21:45airlied: TimurTabi: I'm not seeing many references to it in hte upstream kernel
21:45TimurTabi: Same here.
21:45airlied: at BOOTFB is named once
21:46karolherbst: I suspect it's the fb set up by the firmware :P
21:46airlied: so to remove that you have to use the aperture conflict apis
21:47TimurTabi: I'm not familiar with those
21:47airlied: which change a lot over time
21:47karolherbst: nouveau does use those
21:47airlied: in latest Linus kernel include/linux/aperture.h
21:49airlied: TimurTabi: if you use those the driver has to register it's own fbcon then
21:49airlied: which I believe the out-of-tree doesn't
21:49TimurTabi: This sounds like something that's been around a while?
21:50airlied: it used to be part of drm
21:50TimurTabi: Is this something that changed around 5.15?
21:51airlied: drm_aperture_remove_conflicting_framebuffers
21:51airlied: not sure when simplefb came about either
21:51airlied: but 5.15 would be around that time
21:52airlied: 11e8f5fd223bd4d33fa10527bad3fe48469a15df drm: Add simpledrm driver