06:57AndrewR: hello, all
07:00AndrewR: imirkin, I finally did mmiotrace for my nv92, while playing 10 frames of h264 video file via mplayer. uncompressed file is like ~200Mb in size, no lost events. Can it help with currently-hanging h264 decoding on nouveau? (it works on blob, so hw itself sould be fine)
07:56alexandernst_: "xrandr --listproviders" shows only 1 GPU, but I have 2 identical. (NVIDIA GT610). Is that a bug or an unimplemented feature?
08:08bonbons: alexandernst_: might be auto-config X only uses first nvidia GPU?
08:09bonbons: for kernel side, you can check if you get expected two cards under /sys/class/drm/
08:13alexandernst_: bonbons: yes, I get "card0" and "card1" there
08:13alexandernst_: (and each card with DVI, HDMI and VGA ports)
08:13bonbons: so kernel side is fine. What does your X log say?
08:14alexandernst_: bonbons: I just tried a liveUSB Fedora 21 with X and all 4 monitors worked fine. So there must be something in my install that is disabling the second GPU
08:15bonbons: ^ you X log will probably tell you (note though at if your install has a rather old Xorg while F21 has latest one it can be the cause for non-identical auto-configuration)
08:16alexandernst_: I'm on Arch, so I'm sure my Xorg is newer than Fedora's
08:16alexandernst_: let me check the log
08:16bonbons: (if you can, compare both logs, fedora and arch)
08:17bonbons: and do the same for config files under /etc/X11/xorg.conf* and /usr/share/X11/xorg.conf.d/
08:18alexandernst_: bonbons: check line 756 https://paste.kde.org/peoyuxfam/lrspo4
08:18alexandernst_: why is it removing card1?
08:19jjohn: Is someone able to tell me what the following error message of the kern.log means? "[ 3.977703] nouveau E[ PIBUS][0000:01:00.0] HUB0: 0x10ecc0 0xffffffff (0x1a40822c)"
08:20alexandernst_: I don't get it. It's removing the card, then it's adding it again?
08:20jjohn: imirkin looked into it, but then he got to go.
08:21jjohn: My machine freezes if the system tries to start X. I am using Optimus with a Maxwell card and have been trying to get the driver running. No luck so far, though.
08:24jjohn: I have also looked into the kernel sources and found the function responsible for the error message, but the code is so bad that I have no idea where to start.
08:25mlankhorst: maxwell's tricky
08:27jjohn: mlankhorst well, I already got the firmware, thanks to imirkin's help.
08:28jjohn: BUT: I once tried to get the card running without the firmware, some month's ago. I still have the logs ...
08:28jjohn: And half a year ago the printout was a bit different: "nouveau E[ PIBUS][0000:01:00.0] HUB0: 0x6013d4 0x0000573f (0x1e408200)".
08:29jjohn: So that means that something changed. But as I said, the code is a rotting mess.
08:33bonbons: alexandernst_: to me it looks like runtime-PM might cause you some trouble, check kernel log if there is some info in there
08:33alexandernst_: bonbons: dmesg?
08:37alexandernst_: bonbons: I see kernel is configuring nouveau at line 1003+, but nothing weird https://paste.kde.org/p2krjb1ap
08:40bonbons: nothing notable I would see there. Did you compare with what happens on F21?
08:41alexandernst_: I'd need to reboot and copy both logs. Give me a few minutes
08:44bonbons: go ahead
08:59alexandernst_: bonbons: I'm back. Xorg log https://paste.kde.org/pcftyx0oe Kernel log https://paste.kde.org/pix7h4qa5
08:59alexandernst_: the very first thing I'm noticing from the Xorg log is that Fedora doesn't try to load "nv" module (which I don't know from where it's comming)
08:59alexandernst_: also, I can't see the second GPU being removed anywhere
09:16alexandernst_: bonbons: see anything?
09:21bonbons: alexandernst_: first difference I see is that F21 has older kernel 3.17 versus 3.18 for arch
09:21bonbons: for the rest, hard to tell (you F21 Xorg log seems to be incomplete, missing start of it)
09:23alexandernst_: bonbons: let me try to get the full log
09:23bonbons: so my suggestion would be to disable any runtime power-management that may affect your GPUs. (look for nouveau module parameters in /sys/module/nouveau/parameters/)
09:25bonbons: runpm parameter, if existing, should be the one to look for
09:27imirkin: AndrewR: yes, that'd be helpful. if you can make it available, i might be able to take a look
09:29imirkin: jjohn: i'm not sure what issues you see with the nouveau source _itself_. it's very modular due to the fact that a single driver supports a ton of simultaneously different (in part) and similar (in other parts) gpu's. takes a bit to understand what's going on if you're not familiar with C subclassing techniques
09:35jjohn: imirkin I am talking about stuff nv_mask(priv, 0x122318, 0x0003ffff, 0x00001000); EVERYONE knows IMMEDIATELY what it does and what the values are for. :)
09:35jjohn: That is code that I would ditch without twitching. But that's jus tme.
09:37jjohn: And what's even worse: this code section seems to be at least 2 years old (2012 by Red Hat), and they never touched upon it. Yeah, right.
09:37imirkin: jjohn: no, you don't, but (a) we don't exactly have a ton of docs to know wtf 0x122318 is and (b) it's easiest to have stuff written that way to compare to traces
09:39jjohn: Then just use NV_UNKNOWN_REGISTER_B as a defining, with a comment lke /*still don't know what it does except "bla"*/. This way you just have constants scattered all over your sourced.
09:39imirkin: yeah, it's way easier with the constants :) like i said, it's important to be able to compare to traces
09:40jjohn: There is no other explaination for this code excpet laziness. Sory.
09:40imirkin: and trying to match up NV_UNK_REG_B to a number in a trace is quite a pain
09:40imirkin: anyways, you can obviously have your own opinion, but know that this was an _explicit_ decision taken by the most active developers of the project. it used to all be NV_UNK_REG_B before
09:41jjohn: Then do a preprocessor defining that also gives the name of the constant within kernel printouts.
09:41jjohn: Whatever. I don't want to get started on that.
09:41jjohn: What do you see in the error message?
09:41imirkin: i thought it was dumb at first too, but as i familiarized myself with the project, i've come to realize it was probably the right move
09:42jjohn: >implying you just got aclimated to bad code. ;)
09:42imirkin: i saw how much easier it was with the raw numbers
09:42jjohn: Whatever. That discussion does not help me right now.
09:44jjohn: The time we are discussion this topic does not lead to anything. And I still want to get that sucker running.
09:56imirkin: jjohn: i've never seen that particular error, but i've also only ever had access to a single GM107 card.
09:56imirkin: jjohn: chances are the way this will get resolved is with an mmiotrace and lots of staring
16:58AndrewR: imirkin, https://drive.google.com/file/d/0B84cgTVGGfZaVUZoN1hxNzg4Y00/view?usp=sharing - 8mb xz compressed
17:04imirkin: AndrewR: thanks!
17:53bps_: Is there anything special I need to do to get DRI3 working on nouveau? xcb_dri3_open_reply isn't working
17:54bps_: Also my xorg log only has DRI2 messages
17:55imirkin: bps_: see my response in #d3d9