02:24 bozhan: is someting special needed to make mmio trace of optimus card?
02:25 bozhan: and which is the best way to do it?
02:47 karolherbst: bozhan: nope
02:48 karolherbst: you just need to somehow start a X server for that card, but this has nothing todo with the actual mmiotrace procedure
02:58 bozhan: on howto for ubuntu is suggeted to run xinit "sleep 10", did i have to run : optirun xinit "sleep 10" ?
03:11 karolherbst: boxfire: nope
03:11 karolherbst: "optirun -b none bash" should be fine already
03:12 karolherbst: and with exit you can quit the bash and the card will turn back off and module be unloaded
03:12 karolherbst: (after a while)
05:06 fling: Has NVE0 GK208 (NV108) stability increased since 3.18?
05:34 RSpliet: fling: is that a question or an observation?
05:45 pmoreau: :( It looks like reclocking broke on my MCP79...
05:46 RSpliet: pmoreau: what happened?
05:46 pmoreau: I don't know, it doesn't want to work anymore
05:46 pmoreau: Paste incoming
05:47 pmoreau: RSpliet: https://phabricator.pmoreau.org/P19
05:47 pmoreau: Around 173s-176s
05:48 fling: RSpliet: a question
05:50 pmoreau: Eh, why is it going through GT215 logic? Isn't MCP79 prior to GT215?
05:50 RSpliet: pmoreau: hmm... I don't think anything changed in that code
05:50 RSpliet: yes... but it does call gt215_clk_pre from MCP79, as the pause sequence is the same
05:50 pmoreau: ok
05:50 pmoreau: Guess I'll bisect :)
05:51 RSpliet: well, it gives you quite a big hint :-P
05:51 pmoreau: ;)
05:51 RSpliet: "gt215.c:332" , do you know to what line that maps in the pre-cleanup stage?
05:51 pmoreau: To some weird formulation
05:52 RSpliet: and check whether cleanup didn't accidentally unhook pfifo->pause
05:52 RSpliet: (or all of pfifo)
05:52 pmoreau: RSpliet: http://cgit.freedesktop.org/~darktama/nouveau/tree/drm/nouveau/nvkm/subdev/clk/gt215.c#n332
05:53 RSpliet: ah hmm, I didn't recognise that code back :-P
05:54 pmoreau: Two commits from Ben mainly modifyin it; let's have a look at those
05:55 RSpliet: second read is from the wrong register
05:55 RSpliet: line 329, change 2504 to 251c
05:56 RSpliet: and slap skeggsb around a bit with a large trout :-D
05:57 pmoreau: Ah right, http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=1909665b
06:02 pmoreau: RSpliet: Fixed! :-)
06:02 RSpliet: eggcelent!
06:03 pmoreau: So, now does plugging an external screen works somewhat better...
06:03 pmoreau: :D
06:03 RSpliet: slightly... it doesn't make more mem bandwidth, so I am a bit surprised it helps
06:03 pmoreau: higher mem freq
06:04 RSpliet: it's an IGP
06:04 RSpliet: there is no mem freq :-P
06:04 pmoreau: --"
06:04 RSpliet: hmm
06:04 RSpliet: your VBIOS mentions a memfreq
06:04 RSpliet: interesting
06:04 pmoreau: Well, the blob always bump to perflvl2 or 3 when plugging an external screen though iirc
06:05 RSpliet: don't think it's touched though
06:05 RSpliet: wait, no, let me re-interpret that
06:06 pmoreau: Still getting some warn_slowpath and nothing on the other screen...
06:06 RSpliet: yes, no, there is no memclk :-D
06:06 RSpliet: sorry, got confused with the G96
06:06 pmoreau: No problem :)
06:06 pmoreau: It's a weird laptop
06:07 RSpliet: slightly, not that weird though
06:07 RSpliet: just with an NVIDIA IGP instead of an Intel one
06:08 RSpliet: question is: to which GPU is the secondary monitor connected?
06:08 pmoreau: And a VBIOS which doesn't to initialise parts of the card and let the driver do it instead, on the contrary to every other VBIOS out there
06:08 pmoreau: The iGPU
06:08 RSpliet: ah good
06:09 RSpliet: so that secondary monitor problem I know nothing about
06:09 RSpliet: (sorry)
06:09 RSpliet: but glad you got reclocking back to work. Will you submit a patch, or should I cook it up later (as part of a bigger push)
06:09 RSpliet: ?
06:09 pmoreau: It used to display something, but as soon as I launched some OpenGL stuff, it would flicker as hell
06:10 RSpliet: that does sound like bandwidth problems...
06:10 pmoreau: I don't care, but I'll soon have to go
06:11 pmoreau: Is there some bandwith I can increase on the iGPU?
06:11 RSpliet: very little, as it uses the (already fired up) system RAM
06:11 pmoreau: Cause the blob didn't had any problem running glxgears without flickering iirc
06:12 pmoreau: Whereas Nouveau did
06:14 RSpliet: hmm, yes, well, we might not utilise bw as good as nvidia does
06:14 RSpliet: idk to be honest, there's a mountain of factors
06:14 RSpliet: btw, I'm sorry to ask again, but do I have your VBIOS and trace (in the repo?)
06:15 pmoreau: I don't think so, or maybe only for the MCP79 and G96
06:15 RSpliet: not that I will fix reclocking for the G96 straight away, but it could provide some juicy details :-)
06:15 RSpliet: oh, I meant the G96
06:15 pmoreau: I'll check when I come back (in an hour approx.)
06:15 pmoreau: I have to run
08:07 pmoreau: RSpliet: I had put a trace + strap + vbios in the nvidia_vbios repo :-)
08:07 RSpliet: excellent, thanks for verifying
08:07 RSpliet: I'll use that data to beat the G94 patches into shape
08:08 pmoreau: (But used my new e-mail address -well not that new as I did it in March- so maybe you missed it)
08:08 pmoreau: :-)
08:10 RSpliet: no, I just don't have access to the repo from work :-)
08:11 pmoreau: Well... it can happen! :D
08:18 imirkin: RSpliet: btw, i see reads from 10053c on G86 and probably G84, so i think you have to do that if everywhere
08:19 RSpliet: imirkin: thanks... yes, I did find it odd not seeing those reads on the G94
08:19 RSpliet: although *maybe* the blob does some post-scanning of VBIOS tables to see which features are unused
08:19 RSpliet: ...
08:19 RSpliet: *pre* scanning
08:19 imirkin: RSpliet: my theory back in the day was that it was 100da0 for some split of gpu's, and 10053c for the other
08:19 imirkin: however i have no good ideas re what that split is
08:20 RSpliet: gt21x and nva0 definitely have both
08:20 RSpliet: ... gt2xx
08:20 imirkin: hrmph, ok
08:20 imirkin: and i'm looking at a G84 trace that doesn't have a 10053c read either
08:20 RSpliet: I don't think it matters if I don't put an if() around it, but I didn't even see the read in the trace
08:21 imirkin: yeah that's very odd
08:21 RSpliet: I guess it's easy to find out, just fake a VBIOS, set the one bit, see what the blob does with it
08:26 pmoreau: Was going to ask a question, but I think I found the solution: "ERROR 5 [INVALID_STATE] 0b [] chid 1 mthd 0080 data 00000000" means one of the EVO channel is unhappy about doing an update in the current state, right?
09:12 fling: RSpliet: don't you have an answer for my question?
09:12 RSpliet: fling: oh sorry, too much on my mind atm
09:13 RSpliet: erm... not by heart, but there's been a lot of improvements throughout
09:13 RSpliet: you'd have to go through https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/gpu/drm/nouveau to be sure
09:14 RSpliet: looks like there's been some important work since
09:17 fling: RSpliet: thanks for the info.
09:18 imirkin: fwiw we recently added some bits that let mine (GK208) reclock fine. but i don't use its display capabilities, and that's where a lot of issues tend to crop up. so ymmv
09:19 RSpliet: imirkin: I don't think we've talked about reclocking in particular :-P
09:20 imirkin: and it wouldn't impact stability
09:20 imirkin: but thought i'd mention it
09:20 imirkin: esp since i know he's keen on all the reclocking stuff
09:20 RSpliet: cool :-)
09:21 fling: imirkin: thanks :>
12:19 karolherbst: mupuf: there and got a little time?
13:05 mupuf: karolherbst: not yet
13:05 mupuf: still have some work to do for hakzsam
13:08 karolherbst: mupuf: no problem. I was just thinking, maybe the VID table has to be parsed differently for PWM based chips, because my current table doesn't make much sense. I will maybe toy around a bit until you've got some time then
13:09 karolherbst: *voltage table
13:17 mupuf: I think it is an entirely different table
13:18 karolherbst: somehow I get the feeling that since some fermi chip, the table makes no sense generally
13:19 karolherbst: especially because I find stuff like this:
13:19 karolherbst: Maximum voltage 1213000 µV, voltage step -12500 µV, Maximum voltage to be used 1150000 µV
13:19 karolherbst: Voltage range = 1213000-825500 µV, step = -12500 µV --
13:20 mupuf: we do not understand this table properly
13:21 mupuf: and maybe we should compare nvbios with nouveau's interpretation of it
13:21 mupuf: I am willing to trust ben on this :p
13:21 karolherbst: :D
13:23 karolherbst: mhh
13:24 karolherbst: for(int v= max_volt; v< max_volt_used; v+=volt_sept) // something like that
16:10 karolherbst: uhh, master is no 4.3 based, right?
16:11 imirkin_: master....?
16:11 imirkin_: any particular tree in mind?
16:11 imirkin_: note that ben's tree rebases all the time
16:12 imirkin_: which makes it pretty hard to develop against
16:12 karolherbst: got a compile error against 4.1.6
16:12 imirkin_: yeah, that's expected
16:12 imirkin_: you need 4.2 i think
16:12 karolherbst: ohh
16:12 karolherbst: mhh
16:12 imirkin_: or maybe drm-next, not sure
16:13 karolherbst: don't want to change to 4.2 yet
16:13 karolherbst: but the difference seems to be a minor one
16:13 karolherbst: so patches should be all compatible anyway
16:16 karolherbst: uhh, mhh
16:16 karolherbst: I should have used the linux-4.3 branch, not 4.2
17:16 marcosps1: hello :)
18:09 marcosps1: imirkin: is neu a meta operation too? I can't find it in envytools docs.
18:14 marcosps1: imirkin: (I say meta for the same meaning of merge op...)
19:16 karolherbst: skeggsb: do you know something about that? "timeout at nouveau/drm/nouveau/nvkm/subdev/pmu/gk104.c:44/magic_()!"
19:17 karolherbst: its related to the hack, and I encountered it whily I used the ported patch, but with your stuff it also happens
19:17 karolherbst: I get a few of those and loading time is over 15 seconds
19:19 skeggsb: hm, no. but i think i've currently got access to a machine that needs that fix, so i'll look into it after i've fixed some other things on it
19:19 karolherbst: okay, thanks
19:19 karolherbst: it still works though
19:19 karolherbst: I get 12 timeouts in total
19:25 karolherbst: skeggsb: any good idea how to add non clock information into the pstate sysfs file? I don't want to mess with the interface that much, also maybe you have already a nice idea
19:29 skeggsb: honestly, my preference is to ignore changing any of that for the moment, and work towards fixing all the (many) issues that are preventing us from doing full dynamic reclocking by default.. worry about end-user tweaking after that :)
19:31 karolherbst: I see
19:31 karolherbst: I just wanted to add the pcie speed there, but it wasn't as simple as I thought it would
19:31 karolherbst: so I didn't touch
19:31 karolherbst: it