06:29 cousin_luigi: Greetings.
06:29 cousin_luigi: imirkin_: You around?
06:32 cousin_luigi: imirkin_: Anyway I just wanted to inform you that my system still crashes with 4.0rc5
07:31 imirkin: cousin_luigi: hm, ok. that sucks =/
07:35 lemonzest: cousin_luigi: heh
07:36 cousin_luigi: lemonzest: what are you guffawing at, you citric fiend?
07:38 imirkin: cousin_luigi: are you able to capture logs from the crash?
07:38 imirkin: cousin_luigi: are you able to ssh in after the system has "crashed"?
07:43 cousin_luigi: imirkin: I'm not sure where to look and I haven't tested the other thing.
07:44 cousin_luigi: imirkin: the video freezes while I'm watching a movie and no key combination works
07:44 imirkin: cousin_luigi: hmmmm... freezes only happen with vdpau though?
07:44 imirkin: cousin_luigi: which codec are you using btw? h264?
07:45 cousin_luigi: it's also rather slow compared to nvidia-binary, losing a-v sync above 2x speed
07:45 cousin_luigi: imirkin: I've only tested vdpau and yes, h264
07:46 imirkin: well, that's probably due to the card being clocked low... with 4.0-rc5 if you boot with nouveau.pstate=1
07:46 cousin_luigi: ah
07:46 imirkin: you should be able to clock to a higher speed
07:46 imirkin: (but, most likely, not the max speed)
07:47 cousin_luigi: imirkin: I see. Is there a test that could elicit more clarity about what causes the instability?
07:49 imirkin: sadly no... but if you can come up with repro steps, perhaps someone else can try doing the same thing
07:49 cousin_luigi: imirkin: could part of the log have survived the reboot?
07:51 imirkin: cousin_luigi: sure
07:51 imirkin: although if it's a hard hang, unlikely
07:51 imirkin: you can set up netconsole in the hopes something makes it out
07:53 cousin_luigi: I can't right now, but I'll try and see if I can find something and get back to you.
07:53 cousin_luigi: bbl
08:31 Karlton: okay, I think something changed between xf86-video-nouveau-1.0.11 and xf86-video-nouveau-git that causes artifacts with kde desktop
08:32 imirkin: Karlton: bisect? :)
08:32 imirkin: not a lot of commits...
08:32 imirkin:hopes it wasn't his fault
08:35 Karlton: imirkin: I'll try to learn how to do that and find which one :)
08:39 Karlton: if I set the desktop background as folder view and move the selection box thing, then I notice the artifacts
08:39 Karlton: only happens with git version
08:39 tobijk: Karlton: how do the artifacts look?
08:40 imirkin: well, the big change in git was dri3 support for exa
08:40 Karlton: tobijk: it is very noticeable
08:40 imirkin: however i also pushed some thing which changes some texturing stuff
08:40 imirkin: in a way that i felt was safe, but... heh :)
08:40 Karlton: imirkin: it may not be most recent commit because I don't normally use kde
08:41 tobijk: Karlton: is the problem with window shadows?
08:41 Karlton: tobijk: Do you use kde?
08:42 tobijk: yep, but with an intel card
08:44 tobijk: Karlton: kde has a problem redrawing some things, i just want to make sure it is not that
08:45 tobijk: Karlton: similar to this: https://bugs.freedesktop.org/attachment.cgi?id=97202 ?
08:46 Karlton: tobijk: no, I am pretty sure it has something to do with nouveau x11 driver
08:47 Karlton: it doesn't look like that
08:47 Karlton: only happens when move things in plasma around
08:47 tobijk: ke, not that you try to tackle known kde problems, waste of time :)
08:48 tobijk: well then, can you take a picure of the artifact? (if possible)
08:51 Karlton: tobijk: http://postimg.org/image/sf58paopb/
08:53 tobijk: ok, pulling my old notebook out ... lets see
09:00 Karlton: it for sure doesn't happen with xf86-video-nouveau-1.0.11, let me make sure my ebuilds use the same flags...
09:02 tobijk: i just checked 1.0.11 with mine and it is fine, am just at getting latest git
09:04 Karlton: gentoo does use a glamor patch, maybe I should disable that...
09:05 Karlton: for the stabe version
09:06 tobijk: you are using exa right?
09:07 Karlton: exa?
09:08 tobijk: not glamor
09:09 Karlton: yeah, disabling the glamor patch didn't do anything
09:12 Karlton: I have never used glamor, just gentoo sets it by default with profile switch
09:25 mlankhorst: joi: your solution for tracking nouveau fd's looks like the best one...
09:28 joi: ok...
09:49 Karlton: imirkin: It is the commit that enables dri support without glamor : 241e7289f25a342a457952b9b0e539c2f0b81d99
09:50 Karlton: that one caused the bug
09:50 mlankhorst: heh :p
09:50 mlankhorst: Karlton: try with LIBGL_DRI3_DISABLE=1 in the environment?
09:54 Karlton: mlankhorst: yes, LIBGL_DRI3_DISABLE=1 prevents it from occurring :)
09:59 tobijk: Karlton: can you try with vsync and dri3?
10:00 tobijk: ( its a kde setting )
10:02 mlankhorst: Karlton: what xorg-server version do you have?
10:03 Karlton: tobijk: I had it on and when I turn it off it does not bug
10:04 tobijk: vsync?
10:04 Karlton: yeah, vsync
10:04 tobijk: uhm...
10:05 Karlton: mlankhorst: xorg-server-1.17.1
10:05 Karlton: maybe this an issue kde and dri3?
10:05 mlankhorst: looks like it ;-)
10:05 mlankhorst: or present
10:05 tobijk: yeah :/
10:05 mlankhorst: what exactly is the issue?
10:06 tobijk: http://postimg.org/image/sf58paopb/
10:06 mlankhorst: I saw, not sure how it's supposed to look. :P
10:06 Karlton: mlankhorst: artifacts when I move that selecting box thing around
10:07 mlankhorst: oh that..
10:07 tobijk: :D
10:07 mlankhorst: I thought you meant the topleft, that does look like severe corruption. :P
10:09 Karlton: that was me testing conky
10:09 Karlton: I don't normally use kde, so this must be a kde only issue
10:22 Karlton: actually vsync doesn't make a difference
10:23 Karlton: just dri3
10:24 tobijk: then we mess something up
10:24 Karlton: if anyone wants to test, kde-4.14.3 + dri3 = bad for me
10:24 mlankhorst: or they messed something up :P
10:25 tobijk: Karlton: i'm on the way, i just messed with my system before, cleaning that up and then i'll test
11:05 tobijk: Karlton: can't reproduce with the latest xf86-video-nouveau on nv86 :/
11:07 Karlton: tobijk: you have dr3 enabled in mesa and everything?
11:07 Karlton: dri3*
11:07 tobijk: yep
11:09 tobijk: maybe its your renderpath, you on nvc0?
11:14 Karlton: nve0
11:15 tobijk: yeah that uses the nvc0 renderpath not the nv50 i'm on
11:15 Karlton: ah, okay
11:30 Karlton: tobijk: nv50 is telsa right? I do have a telsa card that I could test
11:30 Karlton: perhaps leaving my system exactly the same and switching the cards to see if anything is different
11:32 adrianlang: Hi, I'm on Debian sid with Linux 3.16.0-4-amd64; when I `modprobe nouveau`, I get HUB_SET_CHAN timeout and my system hangs
11:40 adrianlang: (hang level 8)
11:41 adrianlang: The first thing dmesg logs is `INTR 0x00800000`
11:41 adrianlang: Then there's a lot of `vm timeout`
11:47 Karlton: I got some good news and bad news
11:47 Karlton: good news is that problem isn't me or kde
11:47 tobijk: Karlton: sorry, was away for a bit. Yeah nv50 is tesla: http://nouveau.freedesktop.org/wiki/CodeNames/
11:48 tobijk: ba news? its nvc0?
11:48 tobijk: *bad
11:48 Karlton: tobijk: the bad news is it is nouveau and only with my gtx 650 card
11:49 Karlton: I just simply made sure the bug was happening before I replaced cards and rebooted to find out it does happen with this older card
11:49 tobijk: it does?
11:50 Karlton: it doesn't with telsa
11:50 tobijk: ah doesnt :)
11:50 Karlton: I can't reproduce the bug now
11:50 Karlton: and the only thing I changed was the cards
11:52 tobijk: so the nvc0 renderpath afterall i guess
11:56 Karlton: it for sure doesn't happen with this card "Chipset: GT215 (NVA3) Family : NV50" :(
12:05 tobijk: imirkin: any bells ringing? -^
12:10 kulpae: hello guys, I used to have working DRI_PRIME=1 but now xrandr --listproviders doesnt show my nvidia gpu. lsmod shows loaded nouveau driver and lspci shows both my intel and my nvidia (GT218M [NVS 3100M]) cards. I tried downgrading xorg to 1.16 and 1.15 (together with the drivers and deps) with no effect
12:10 tobijk: kulpae: maybe you got an system with DRI3, where you dont have to do the xrandr dance anymore?
12:12 kulpae: thats possible, but shouldn't DRI_PRIME=1 glxinfo show Mesa and not Intel Open Source then?
12:13 kulpae: ok, I'll try downgrading the kernel, that may help...
12:13 tobijk: nah
12:14 tobijk: kulpae: can you do "DRI_PRIME=1 glxinfo | grep vendor"
12:14 tobijk: just to be sure :)
12:15 kulpae: server glx vendor string: SGI
12:15 kulpae: client glx vendor string: Mesa Project and SGI
12:15 kulpae: OpenGL vendor string: Intel Open Source Technology Center
12:15 tobijk: ke
12:16 tobijk: can you grep dmesg and pastebin it?
12:17 adrianlang: I also get HUB_SET_CHAN timeout with Linux 3.18.0. I have an NVD9 card
12:18 adrianlang: (which is NVC0 family)
12:18 kulpae: http://pastebin.com/DCKe1DQs
12:20 tobijk: looks fine
12:20 tobijk: and now Xorg.0.log
12:21 kulpae: ok
12:22 kulpae: http://pastebin.com/yGMJbMZT
12:26 tobijk: kulpae: you are missing xf86-video-nouveau
12:26 tobijk: the x driver for nouveau
12:26 kulpae: xf86-video-nouveau 1.0.10-2
12:26 kulpae: lsmod shows: nouveau 1344416 1
12:27 tobijk: yeah not the kernel mod, thats all fine
12:27 tobijk: the x driver
12:27 tobijk: xf86-video-nouveau
12:27 tobijk: the x server does not load it
12:28 tobijk: kulpae: "ls /usr/lib/xorg/modules/drivers/"
12:29 kulpae: intel_drv.so nouveau_drv.so
12:29 kulpae: ok, to know that already helps me... so it's blocked from loading for some reason...
12:29 kulpae: and It's not blacklisted afaik
12:31 kulpae: hmm, thats strange... reinstalling xf86-video-nouveau doesn't update nouveau_drv.so (Dec 28 2013)
12:32 tobijk: look in the package where the driver gets intalled to
12:33 kulpae: oh nevermind, it's an old binary from 1.15 xorg repository
12:34 kulpae: but the latest version didn't work before downgrading as well
12:35 kulpae: and pacman -R removes nouveau_drv.so, so it's the right one
12:36 kulpae: ok, I'll reupgrade xorg and drivers to 1.17 and come back, ok?
12:37 tobijk: yeah that one has a more verbose output, might help
12:37 kulpae: ok, back in a minute
12:41 kulpae: ok, here is the new dmesg: http://pastebin.com/Rp8s9dxP
12:42 kulpae: and Xorg.0.log: http://pastebin.com/cNtKgLzK
12:42 kulpae: ls /usr/lib/xorg/modules/drivers shows: intel_drv.so modesetting_drv.so nouveau_drv.so
12:43 kulpae: DRI_PRIME=1 glxinfo | grep vendor is still: OpenGL vendor string: Intel Open Source Technology Center
12:45 RSpliet: what about xrandr --listproviders ?
12:45 tobijk: you are missing:
12:45 tobijk: [ 27.155] (==) Matched intel as autoconfigured driver 0
12:45 tobijk: [ 27.155] (==) Matched nvidia as autoconfigured driver 1
12:45 tobijk: [ 27.155] (==) Matched nouveau as autoconfigured driver 2
12:45 tobijk: these autoconfig section somehow
12:46 tobijk: RSpliet: he is not loading the xf86-video-nouveau, without that, no provider for nouveau
12:47 RSpliet: tobijk: ok, fair enough, I wasn't entirely sure how that works (since you don't need DRI_PRIME for 2D accel...)
12:48 tobijk: that is only the case for DRI2 though
12:49 kulpae: so your Xorg.0.log shows these Mathced driver lines? hmm, how can I get them to show up then?
12:51 tobijk: kulpae: yeah it does show these lines and i'm not sure how to config that
12:51 imirkin: adrianlang: pastebin dmesg
12:51 tobijk: imirkin the xorg log does show the nouveau card
12:51 tobijk: its just not loading the driver :/
12:53 tobijk: kulpae: you have some stale config in /etc/X11/xorg.conf.d ?
12:53 tobijk: something with nouveau?
12:53 imirkin: tobijk: there have been a lot of things said by kulpae... i haven't kept track... what's the issue?
12:54 kulpae: nope, only synaptics and no /etc/X11/xorg.conf
12:54 tobijk: imirkin: he cant offloa to nouveau on a prime system, kmod is loaded fine, xserver shows the card, it just does not load the nouveau_drv.so with the xserver
12:55 imirkin: kulpae: you have a driver section for intel
12:55 imirkin: kulpae: grep -r intel /etc/X11/xorg.conf*
12:56 kulpae: nothing
12:56 tobijk: oh he does ~_~
12:56 imirkin: hmmmmm
12:57 imirkin: as tobijk pointed out, you seem to be missing the autoconf stuff
12:57 imirkin: kulpae: [ 4.422] (**) intel(0): Option "Backlight" "intel_backlight"
12:57 imirkin: kulpae: find where that's coming from -- this is what's breaking everything for you
12:57 kulpae: ok grepping etc and usr
12:57 imirkin: this option is specified in some config file
12:58 imirkin: kulpae: perhaps in /usr/share/X11/xorg.conf.d
12:59 kulpae: yes here: /usr/share/X11/xorg.conf.d/20-intel.conf
12:59 tobijk: remove that file
12:59 imirkin: joi: wow, that's crazy -- how did you even find that?
12:59 tobijk: you got more files in that foolder?
13:00 imirkin: joi: i'm going to have to think about what it's doing and whether there's a better way, but... wow. well found!
13:00 kulpae: and there is: /usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf with http://pastebin.com/SwnRB8d3
13:01 tobijk: if you dont want to use the nvidia driver, away with that :>
13:02 joi: I used mmt on nouveau and noticed GEM_CLOSE on a vertex buffer _before_ it was used in a pushbuffer
13:02 joi: imirkin: ^
13:02 kulpae: ok the nvidia one came with xorg-server 1.17.1-4, but the intel one doesn't have a package associated, I'm removing it
13:03 kulpae: ok, back in a minute
13:03 imirkin: joi: does this also perchance fix the weirdo hunks in Unigine Heaven?
13:03 imirkin: squares popping up left and right at random
13:04 joi: imirkin: and I looked at vertex buffer because its gpu address matched the one which was reported as pte fault
13:04 joi: no idea, I didn't test it
13:05 joi: btw, I observed no changes in piglit with this patch
13:05 kulpae: OpenGL vendor string: nouveau
13:05 imirkin: joi: ok, well, very cool. like i said, give me a bit to think about whether this is the right way to go
13:05 kulpae: thanks its the culprit
13:06 kulpae: xrandr --listproviders shows both gpus now :D
13:06 joi: imirkin: I think this scratch buffer code is still broken, but in different way
13:06 imirkin: [among other things i need to remember wtf the scratch runout stuff is... something to do with vertices, but... what. heh.]
13:07 joi: I think it reuses some buffers which are still used by previous commands
13:08 imirkin: yeah, that scratch stuff was always a bit odd... but the fence logic is also very subtle and difficult to follow :)
13:08 tobijk: ah imirkin, Karlton could test his kde render problem with nv50, it does not happen there, only with the nvc0 renderpath
13:08 kulpae: thank you very much, that was a huge blocker for weeks for me :D have a nice day, you both helped me a lot, cya
13:08 imirkin: joi: based on this insight though, perhaps consider adding some demmt features to automatically yell when it sees funny business like that?
13:08 joi: nice idea :)
13:09 joi: yes, it's definitely possible
13:09 imirkin: it'll invariably sometimes be wrong (random values will match up to things), but given its buffer tracking, should be feasible.
13:10 imirkin: tobijk: sorry, my knowledge of the ddx is quite limited
13:11 tobijk: imirkin: just noting in case any bells are ringing :)
13:12 imirkin: none, sorry
13:12 imirkin: someone's having trouble with nv50 though ;)
13:18 Karlton: imirkin: The same kind of trouble?
13:19 imirkin: nope
13:21 joi: imirkin: btw, I could workaround this bug by avoiding "scratch runout" code by increasing size of static scratch buffers (with this patch: http://paste.ubuntu.com/10703502/ )
13:25 adrianlang: imirkin: Nothing to pastebin since it hangs afterwards. As I said, it's `INTR 0x00800000`, then `HUB_SET_CHAN timeout` and then lots of `vm timeout`
13:25 imirkin: adrianlang: try to get fuller logs. at this point i have no clue what hardware you're even on.
13:25 imirkin: often earlier messages are important too
13:26 imirkin: adrianlang: you can use netconsole if you have a second computer
13:36 adrianlang: imirkin: There's no earlier message. This comes right after `modprobe nouveau`
13:36 adrianlang: I'll do netconsol
13:36 adrianlang: e
13:36 imirkin: adrianlang: nouveau outputs a bunch of info messages
13:41 pamaury: Hi, I have a question: does nouveau support audio over display port ?
13:41 imirkin: pamaury: yeah, but only with recent kernels
13:42 imirkin: pamaury: probably starting kernel 3.16
13:42 pamaury: on all chips ? I'm running 3.16 so I guess it's not recent enough ?
13:42 imirkin: nva3+ i assume...
13:45 imirkin: pamaury: i lied... looks like 3.18+
13:45 pamaury: I have nv98..
13:45 imirkin: oh... that weirdo dual-gpu board?
13:46 pamaury: err no, that's a quadro fx 370m
13:46 imirkin: oh ok
13:46 imirkin: very questionable whether it'll work or not
13:46 pamaury: but the audio wiring is wired on this laptop, even with the binary driver it was shaky
13:47 pamaury: ok I'll wait for 3.18 and see ^^
13:47 imirkin: there are a ton of parameters that nouveau doesn't set
13:47 imirkin: so you either get lucky or not wrt the audio stuff
13:47 imirkin: starting with nva3, there's an actual hda codec
13:48 imirkin: and it's all much more likely to work
13:48 pamaury: ah better, because on mine it's an "spdif input" to the hda codec
13:48 imirkin: right
13:48 imirkin: whereas on newer boards, there's a gpu subfunction that provides a separate hda codec
13:49 imirkin: e.g. 02:00.1 Audio device [0403]: NVIDIA Corporation GF108 High Definition Audio Controller [10de:0bea]