00:16Lyude: sweet, looks like there WAS a watchdog on this system after all, it's just built into the super i/o chip?
00:16Lyude: amd is weird. but i like it
02:25karolherbst: imirkin: did you take a look at what we have to do for ARB_transform_feedback_overflow_query?
02:26karolherbst: shouldn't be too much work, should it?
02:29imirkin: shouldn't, but ... probably will be.
02:30imirkin: it has resisted some modest attempts at my understanding wtf it was doing
02:30imirkin: but tbh i didn't spend too much time on it
02:30imirkin: the main difficulty is that we get overflow by stream, but this query needs to allow querying the "overall" status
03:35mischmerz: Evening ;)
05:35orbea: imirkin: seems mpv hwdec is still sometimes problematic for nouveau, it crashed nouveau when switching to the next video in the playlist, but doesn't occur everytime. Here is the dmesg output with a call trace if you're interested. http://dpaste.com/2VPP2CG I fully understand if this is not investigated, but I thought its at least worth mentioning
05:38orbea: 4.14.12 kernel btw
08:41kabads: It seems that nvidia have stopped support for my card - it was working fine on 304. I thought I'd give nouveau a go. It's a GeForce GT 130M - is this supported by nouveau?
08:41kabads: I've installed it, and the screen flickers, but I only get 3 grey bars, before it returns back to console/fb.
08:49karolherbst: kabads: mhh, actually it should work
08:50karolherbst: I guess something X related is unhappy
08:50karolherbst: if the console works and nouveau is loaded, then stuff already works. I would check dmesg and the X logs
08:50karolherbst: maybe nvidia still gets loaded
08:50karolherbst: or the nouveau kernel driver loads, but nvidia userspace is started
08:50karolherbst: nvidia usually puts a xorg.conf somewhere, which you won't need with nouveau
08:51karolherbst: and then there are several blacklists entries nvidia installs as weill within /etc/modprobe.d/
08:51karolherbst: it's never pleasent to tidy up a nvidia installation
08:52kabads: karolherbst: I dealt with the blacklist, so nouveau isn't affected there. I think it's the config file. I'm using the same config as nvidia, but obviously changing the driver name to nouveau.
08:52karolherbst: well, that won't work
08:52kabads: karolherbst: Thankyou for the tips.
08:52karolherbst: just remove it
08:52karolherbst: you won't need a x config file except you have a really really rare setup
08:53kabads: karolherbst: if not needing a xorg.conf file is true, then you've made my day. I've spent hours trawling through them over the past couple of decades.
08:54kabads: I'm running arch linux, and the wiki there refers to xorg.conf, but using a tool Xorg :0 -configure to get a blank one. That didn't work.
08:54karolherbst: well open source drivers don't require any xorg.conf files for years
08:54karolherbst: and suggesting you should create one is silly
08:54kabads:has been running with nvidia for too long now.
08:55kabads:checking wiki again.
08:55karolherbst: you need one if you run multiple displays on multiple GPUs and kind of want one complete desktop
08:55karolherbst: or for dev purposes
08:58kabads: OK - thankyou again. I missed a part where the wiki points to /etc/X11/xorg.conf.d/20-nouveau.conf - that's now set up, but with the same set up. modprobe nouveau works fine.
08:58kabads: dmesg does point out some problems.
08:59kabads: NVRM: failed to register procfs!
09:00kabads: And then it goes on about conflicting drivers being loaded by the kernel. There's obviously something hanging around from nvidia
09:04kabads: should nouveau be loaded under drm?
09:09kabads: OK - this is strange - root can run X, but not my normal user.
09:10kabads: It's probably my .xinitrc or something - anyway, it's working.
09:11kabads: It doesn't like i3wm
09:11kabads: Is that a bug?
09:12kabads: or does it not use .xinitrc?
09:12kabads: by it, I mean nouveau.
09:14pmoreau: Nouveau does not use .xinitrc, but X will.
09:15kabads: pmoreau: of course. Hmm.
09:15karolherbst: kabads: depends what you mean by doesn't like i3wm
09:16karolherbst: kabads: the painful part is, that if nvidia userspace stuff is accessed, it usually starts to load the nvidia kernel driver as well
09:16karolherbst: so you really want to get fully rid of it
09:16kabads: Without the .xinitrc I get a typical twm load, but as soon as I include a .xinitrc file with the single entry exec i3wm then it attempts to load, and then shuts down (with no errors).
09:16pmoreau: Except the NVIDIA kernel driver usually bails out if it detects Nouveau.
09:17karolherbst: kabads: does i3wm uses opengl these days?
09:17kabads: karolherbst: good point. I'll try xfce
09:17karolherbst: kabads: check glxinfo
09:17karolherbst: if starting with twm
09:17karolherbst: because you really want to get this right before trying anything fancy
09:17karolherbst: and glxinfo should show nouveau obviously
09:18kabads: black screen with xfce4-session but no exit or crash.
09:21kabads: exec twm in .xinitrc gets the same (black screen with no crash). No .xinitrc file loads twm fine.
09:21kabads: Which files in /etc/X11 are necessary? I don't want to clear them out when they might be needed.
09:23karolherbst: kabads: the default ones
09:23karolherbst: like all which are installed by your package manager
09:23kabads: Right. Perhaps a reinstall of Xorg might work - I'll backup the directory first. Thankyou all for your help.
09:23karolherbst: I doubt the X package installs them, maybe it does... who knows
09:24karolherbst: usuay you can query and see what installs what
09:24karolherbst: usually package shall install them inside /usr/share/X11/xorg.conf.d in the first place
09:25kabads: Thought so. That's what the wiki refers to.
10:14karolherbst: Lekensteyn: I plan to fix that runtime pm bug on my Dell XPS 9560 and might need some help regarding understanding that ACPI stuff involved in this
10:45karolherbst: Lekensteyn: do you know anything about a _SB.PCI0.PEG0.PEGP._PRW method?
10:48drizztbsd: hi, I'm trying to use nouveau on a GTX 970 (aka GM204), but it creates bad glitches (KDE with composite enabled)
10:48drizztbsd: any workaround?
10:49gnarface: compositing is probably still broken
10:49gnarface: for nouveau
10:49karolherbst: timothy: depends on the glitches, but there are some inherent problems using plasma5. Nouveau doesn't do well if you have too many OpenGL contexts
10:49karolherbst: gnarface: nah, compositing is fine
10:50karolherbst: it just that nouveau doesn't like to have a lot of OpenGL applications at the same time
10:50karolherbst: kind of
10:50timothy: black blocks, part of text corrupted, etc
10:50karolherbst: those look like bugs within the DDX or mesa
10:51karolherbst: timothy: could you try to trace an application with apitrace, which has those issues and see if they appear on a replay?
10:52karolherbst: timothy: what applications are we talking about by the way, maybe I could try to kind of reproduce the issues here. I have a GP107 and I expect that if we have issues on a GM204 I should see them on a GP107 as well
10:54timothy: ofc if I use Xrender as compositor I don't have the glitches
10:55timothy: karolherbst: fresly installed Fedora 27 KDE spin, open terminal, write some characters... glitches
10:55karolherbst: okay, seems like some kwin related issues then... mhhh
10:57timothy: btw I'm ok with Xrender atm. I'll check if other opengl application have glitches
10:57karolherbst: I'll try what I can figure out. Tracing kwin is a bit weirdo weird
10:58karolherbst: timothy: well, there are some known OpenGL issues in rather complex OpenGL applications like in unigine... it's hard to tell what is related to waht
10:58karolherbst: so in general an apitrace is the best way on how to debug those things
11:17imirkin: timothy: sounds like you enabled DRI3?
11:17imirkin: timothy: or perhaps you're using xf86-video-modesetting
11:20timothy: imirkin: by grepping the log file you are right, but it's Xorg that loads modesetting by default
11:21imirkin: not with upstram code
11:21imirkin: but some distros have sadly made that change locally
11:21timothy: ok, so Fedora have that change locally
11:27timothy: imirkin: it worked, I forced nouveau by adding a Section Device with driver nouveau in xorg.conf.d and now no glitches anymore
11:27timothy: thank you
11:27Lekensteyn: karolherbst: "_PRW is only required for devices that have the ability to wake the system from a system sleeping state."
11:29imirkin: timothy: feel free to complain to your distro. i've been ignored thus far.
11:30Lekensteyn: karolherbst: on my Clevo P651RA, disabling a wake related line in the PGOF method had no effect (no improvement) IIRC (I think I patched the SSDT to test that out)
11:30imirkin: (or perhaps ignored is the wrong word... overruled is probably better.)
11:31kherbst: Lekensteyn: I see
11:32kherbst: Lekensteyn: well currently I try to figure out how to suspend/wake up the GPU just using ACPI methods
11:32kherbst: but a simple _OFF _ON cycle already messes it up
11:32kherbst: talking about _SB.PCI0.PEG0.PG00
11:32kherbst: so I assume we have to call something in addition to \_SB.PCI0.PEG0.PG00._ON
11:32kherbst: or do some preparations
11:33kherbst: Lekensteyn: do you know what those \_SB.PCI0.PEG0.PEGP.GC6I methods do?
11:34kherbst: and \_SB.PCI0.PEG0.PEGP.GC6O
11:35Lekensteyn: kherbst: let me see if I can find something for cbeca351-067b-4924-9cbd-b46b00b86f34
11:42kherbst: Lekensteyn: it is guarded by a TDGC == One check
11:42kherbst: any idea what that TDGC field is for?
11:44Lekensteyn: kherbst: I suspect it flags an older, non-(ACPI-)standarized proprietary method that is only used when explicitly enabled by the nvidia driver
11:44Lekensteyn: see line 984 of ssdt2.dsl
11:44Lekensteyn: function 3
11:44kherbst: I think I have another kind of firmware
11:48kherbst: anyway, rebooting time :(
11:51karolherbst: Lekensteyn: what I don't quite get is, why those ON/OFF methods don't really work as expected. I mean, OFF works, we know that
11:51karolherbst: but ON?
11:52Lekensteyn: that ssdt reference was for product_name:XPS 15 9560 from bios_date:05/08/2017 bios_version:1.3.3 btw
11:53karolherbst: I have bios version 1.5
11:53Lekensteyn: and why ON fails is also a mystery to me, using acpi_osi can force the new code path to be disabled, the difference between the two code paths should teach us something but I have not pinned it down
11:54Lekensteyn: I probably posted this to you before, but these are my notes: https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt#L94
11:55karolherbst: well, so the windows 10 way is broken? and the firmware defaults to that?
11:55karolherbst: or well
11:55karolherbst: Linux just stays I support whatever
11:56Lekensteyn: well, the windows 10 way triggers it
11:56Lekensteyn: (actually, windows 8)
11:56Lekensteyn: depending on model
11:56karolherbst: that \_SB.PCI0.PEG0.LNKS looks weird
15:13karolherbst: mwk: are you aware of anything related to memory self refresh on nvidia hardware? I know that there are some regs documented in rnndb for this, but I am more interested in on how to actually use that.
15:53danboyd: I'm experiencing a replicatable crash in gnome-shell/wayland on my ThinkPad W530 (NVidia Quadro K1000M). I'm running Debian testing with the liquorix kernel, though I am also getting the same behavior from the Debian kernel. I'm currently running 4.14.0-12.1-liquorix-amd64
15:53danboyd: dmesg: https://pastebin.com/mffEEvE3
15:54danboyd: I am able to ssh into the machine. It is currently locked up and I have an active ssh session
15:54danboyd: the crash happens almost every time I resize a window
15:54danboyd: mouse cursor stops moving; num lock stops responding, etc
15:54karolherbst: somebody mentioned that resizing firefox kills it as well
15:55danboyd: yes -- that's what I was doing when it crashed. resizing a firefox window
15:56danboyd: any workarounds for the time being? this is my production work machine
16:01danboyd: if i roll back to an earlier kernel, any versions I should avoid? any stability issues with 4.12 or 4.13?
16:04karolherbst: not quite sure
16:04karolherbst: I think somebody wanted to look into that issue
16:04karolherbst: Lyude maybe?
16:05karolherbst: but debugging those shader traps is kind of annoying really
16:05karolherbst: somebody would need to write a proper trap/exception handler
16:05danboyd: ok. i'm rolling back to 4.12 for the time being. I'll hang out here for awhile in case they log in. I can replicate the issue later if need be. should I pastebin any other logs before I reboot?
16:05karolherbst: does this issue not happen with 4.12?
16:05karolherbst: wondering why
16:05danboyd: heh i'm about to find out :)
16:06danboyd: there is some version that I was using recently that was stable. I don't remember which one
16:15danboyd: ok -- rebooted into 4.12 now and just resized a firefox window without incident. will report back if it does eventually crash
16:24imirkin_: danboyd: if it's a kernel change that's responsible, a bisect will probably be required to identify it
16:25imirkin_: 4.14 did get a new vm handler
16:25imirkin_: or is that 4.15
16:46danboyd: ok -- i'm on a project this morning (US CST); but happy to help out however i can after lunch
16:54danboyd: ok so to do a bisect, I need to check out the source tree for both versions?
16:58karolherbst: danboyd: well, you just need a git tree of linux and mark one bad and a good commit
18:00danboyd: ok ... did some testing. I have 3 different versions of 4.14 -- two liquorix and one debian. all three will crash almost immediately if i open firefox and start resizing the window. 4.13, meanwhile, appears to work. going to attempt a bisect here in a minute.. never done one before, so i may have questions
18:01imirkin_: search for "linux kernel git bisect"
18:13Asu: i believe we might have the same issue, danboyd
18:14Asu: on gtx 760, i get a hang when closing a terminal while firefox (haven't tried with other apps tbh) is open, with compton and i3wm
18:14Asu: happens randomly, i did report a bug a few days ago, though i didn't try on older kernels
18:21danboyd: for me, i can log in, open firefox, resize the window a bit and it crashes within a second or two
18:22danboyd: i'm compiling the latest kernel from git to see if the issue is still there
18:31Asu: since i actually used i3wm, the resizes were only happening once in a while... perhaps i'll try again tonight to see if it also happens when changing the size
19:07Lyude: karolherbst: I think it might have gotten fixed in a newer kernel but I'm not sure, nrr?
19:07karolherbst: no idea
19:07Lyude: nrr would know since I had them try a new kernel
19:07Lyude: iirc they said it fixed it
19:09danboyd: i'm compiling the latest from git now.. will report back if it's fixed
19:37nrr: Lyude: yeah, but i did more than just upgrade the kernel. i have it noted that upgrading alone didn't fix it and that i changed a couple other variables in my setup. just haven't had time to isolate which one did it and why.
19:37Lyude: hm, alright
19:38Lyude: well I've got a machine I can reproduce this with so when I get a chance I will take a look
22:08danboyd: just saw this article. is nouveau impacted by this? https://www.engadget.com/2018/01/10/nvidia-gpu-meltdown-and-spectre-patches/
22:09airlied: danboyd: the whole kernel is
22:10imirkin_: and our shader compiler does nothing to avoid any cross-task leaks
22:10imirkin_: but ... there's so many leaks when you use nouveau, that ... heh
22:11glisse_: nouveau is a plumber dream ! Super Mario help us :)
22:58robclark: danboyd, nouveau gets recompiled when your distro kernel is updated, nv blob ko does not..
23:24Lyude: mupuf: btw; I'm assuming it's not a problem if we end up landing CG/BLCG/SLCG at the same time, but just for kepler1/2?
23:24Lyude: nothing stopping me from doing maxwell1, just figured it's about time to send this to the ML since the series is mostly cleaned up at this point