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