04:20karolherbst: can anybody explain to me, why the clocks inside the cstates seems to be doubled or the marketing clocks are halfed?
04:24pmoreau: karolherbst: Not me! :-D
04:25karlmag: Different realities? :-P
04:25karolherbst: pmoreau: well I already answered you :p
04:26pmoreau: Haven't seen your answer yet, just came back from lunch and checked IRC
04:27karolherbst: I see
04:28pmoreau: Ok, saw your answer :-)
04:29karolherbst: pmoreau: in the vbios my gpu also only have 2004MHz memory clock, but it was sold with 4008MHz
04:30karolherbst: it is just a big mess all this
04:30karolherbst: who know what the _actual_ clock is
04:31karolherbst: pmoreau: actually I can't use 0 in the error state :/
04:32karolherbst: meh I have to improve error handling there a bit
04:35karolherbst: pmoreau: the painfull part is, that this table is the only place where we get the information what "unboosted" clocks actually are
04:35karolherbst: and if we fail to parse that table
04:35karolherbst: then it is a big mess
04:38karolherbst: I think I got it now
04:39karolherbst: when we have a cstep table and this base clock table, we use a clock from there, but if we don't have them we use the old PM_mode table to determine the clocks
04:45karolherbst: pmoreau: https://github.com/karolherbst/nouveau/commit/0c593e873cb8d903fc989afe32b8ee3e8e643fb4
04:45karolherbst: but for this I need to verify what the blob does, when this table contains garbage
04:52pmoreau: The new commit seems better. :-)
04:53pmoreau: xexaxo: You have a point, about 0, 1, 2. :-D
05:00karolherbst: if the cstep table and the base clock table are invalid
05:00karolherbst: blob sticks with PM_Mode clocks
05:04karolherbst: mhh, so this base clock table seems to be just irrelevant for the clock the blob boosts to, but it still tells the driver which is the basic clock the gpu shall run on
05:05karolherbst: 1032 (valid base clock table) vs 810 (broken table)
05:05karolherbst: but it still boost to the same clock
05:09karolherbst: I have no idea where this 1123MHz comes from though
05:10karolherbst: ohhh wait :O
05:10karolherbst: there is a boost limit inside mupuf vbios
05:10karolherbst: never saw that before
05:13karolherbst: maybe I found another table
05:14karolherbst: ohh no, it is just the boost table
05:24xexaxo: pmoreau: thanks. the ddr does as well... although I'm not sure where (which exact memory types) are x2'd
05:32pmoreau: xexaxo: I did thought of DDR, but I discarded that idea since it also applied to core clocks. Thinking about it again, it would be really weird to have core / shader clocks in *normal* rate, and memory clocks in DDR rate.
05:33RSpliet: wasn't it the case for a while that shader clock was simply core clock *2?
05:36pmoreau: Could be… Haven't really looked at them
05:40karolherbst: I found something out about boosting :)
05:40karolherbst: mupuf: your voltage map entry 1 seems to give the driver the voltages for boosting
05:40karolherbst: like if you higher them, the blob clocks/volts higher
05:41karolherbst: if you lower them, then the clock/voltage gets lower
05:41mupuf: hmm, not sure what you are doing here
05:42karolherbst: you know that each cstate has a voltage map entry?
05:42karolherbst: sure you know ;)
05:42karolherbst: some entries aren't used by cstates
05:42karolherbst: for example, if you look at this entry: "-- ID = 1, link: 3d, voltage_min = 1150000, voltage_max = 1150000 [µV] --"
05:43karolherbst: and the linked one: "-- ID = 61, link: ff, voltage_min = 0, voltage_max = 25000 [µV] --"
05:43karolherbst: 1150000 + 25000 is the max voltage used while boosting
05:43karolherbst: if you lower ID 1 voltage to 1000000
05:43karolherbst: the blob only boost to a voltage of 1000000 + 25000 uv
05:44karolherbst: and a lower clock of course
05:44mupuf: and what references this voltage map entry_
05:44karolherbst: no idea
05:44karolherbst: searching for it currently
05:44mupuf: sorry, was blocked in the finnish layout
05:45karolherbst: but this was very obvious that the blob reacts to this value
05:45karolherbst: because the set VID fits to it
05:46mupuf: having fun on reator?
05:47mupuf: I investigated the drops/blocking behaviour yesterday
05:47mupuf: I was sick at home
05:47mupuf: the problem comes from the router
05:47mupuf: cisco router...
05:47mupuf: I tried disabling a ton of stuff but it is still there
05:48karolherbst: NSA doesn't like nouveau, that simple
05:48mupuf: ah ah
05:48mupuf: so, I need to check out what is going on, because it is fucking annoying
06:08karolherbst: mupuf: maybe the first two entries have a fixed meaning for all cards? :/
06:08mupuf: I doubt it, look inside the header of the table
06:08mupuf: maybe the entry 1 is referenced from there
06:08mupuf: or better, from the pstate
06:09karolherbst: yeah maybe
06:09karolherbst: 0x751e: 20 0c 22 40 01 c8 00 01 00 02 00 00
06:09karolherbst: there are two 01 values :D
06:09mupuf: try to change the last one to a bigger id
06:09mupuf: and see if it changes the boost clock
06:17karolherbst: mupuf: is there support for openwrt for your router? :D
06:17mupuf: not for cable modems
06:18karolherbst: ohh really?
06:19karolherbst: sad ./
06:20karolherbst: mupuf: okay changing the 01 has a strange effect
06:21karolherbst: the voltage is still 1.175V, but only 836MHz clock
06:21mupuf: you are on the right track
06:22nchauvet_: karolherbst, no, only xorg.conf.d files related to input
06:22mupuf: have to go to my Finnish class, see you!
06:22nchauvet_: hum, sorry, wrong tab...
06:22karolherbst: mupuf: yeah, the clock related to the voltage set though
06:23mupuf: ok, it may just be a bug on nvidia's side, but we need to match it :s
06:23mupuf: anyway, have to run!
06:23karolherbst: yeah I will try to figure it out
06:28karolherbst: mupuf: now it fits :)
06:28karolherbst: I think if you go under the "voltages" for a pstate, the blob messes up
06:28karolherbst: but as long as you keep above, it works
07:49Hauke: where do I find the nouveau development git tree which will go into linux 4.5?
07:49imirkin: Hauke: http://cgit.freedesktop.org/~darktama/nouveau/
07:50imirkin: Hauke: it should have your patch to support 225mhz hdmi on fermi... and a kernel param to override it to higher frequencies
07:51Hauke: imirkin: thanks
07:52Hauke: that was the information I was actually searching for ;-)
07:53imirkin: someone with a GF106 said they could get up to 297mhz... no idea where that info comes from though :(
07:53imirkin: so i just threw a kernel param in and called it a day
07:55imirkin: [i also asked the nvidia guys about how to detect it, but no info so far]
07:55Hauke: imirkin: I have a GF114 and I think I tried something bigger than 225 and it failed, the blob also limits at 225 mhz
07:56imirkin: right, so the 225mhz thing is a real thing... just not for everyone :)
07:56imirkin: maybe it's chip-specific, maybe it's board-specific
07:56imirkin: i found something promising in the vbios, but it said 225mhz for that GF106 guy
07:59Hauke: an older blob only allowed 165 mhz max, but a recent blob allowed 225 mhz
08:00Hauke: imirkin: I have only one nvidia graphics card to test here
08:00imirkin: Hauke: right, i'm not suggesting that you would do anything in addition to what you've done :)
08:01imirkin: that's why i asked the nvidia guys... hard to get all the equipment in the right place to test it all out, not to mention time-consuming
08:05Hauke: for SoC kernel-ci is helpfull
08:11karolherbst: imirkin: maybe it is just a "marketing" limit or a stability thing, at which clock did he used the clock in the end?
08:12karolherbst: or was the card sold with support for 297?
08:12imirkin: karolherbst: the GF106 guy said that the blob driver allowed 297, and he was able to use it just fine at 297
08:12imirkin: which happens to be the freq for 4k@30 or something like that
08:12karolherbst: imirkin: ahh k
08:12imirkin: whereas Hauke's experience is that the blob allows 225, and he's only able to go up to 225
08:15karolherbst: I am just wondering about stuff like that sometimes, because, I don't know if this is still a thing, but years ago you could just hack some engine cores free if you flashed your vbios and get more perf that way
08:16imirkin: karolherbst: and now you know how it worked :)
08:17karolherbst: yeah of course, but I am wondering if that is still a thing
08:17karolherbst: like is my gpu able to do more (not only freq/voltage wise) but has it actually more stuff on the chip than advertised through the vbios
08:18Hauke: I do not know for sure what happend when I used it with more than 225
08:19imirkin: karolherbst: oh like masked off TPC/etc?
08:20Hauke: could it be that the max pixel clock also depends on some off chip stuff?
08:20imirkin: Hauke: yep
08:21imirkin: could depend on everything including the physical connector wired onto the board
08:23Hauke: lets see what the nvidia people will answer
08:25karolherbst: pmoreau: just sent a better version of the series :)
08:25karolherbst: but I think my finding today may solve the main mystery about boosting
08:26karolherbst: the other part would be the algorithm for tdp/temp/max_clock => actual_clock
08:26karolherbst: but we do have the max_clock now
08:36karolherbst: prg_: do you know if nouveau clocked much higher with your kepler card than the binary driver did?
09:48joi: imirkin: still interested in running warsow windowed?
09:48imirkin_: joi: not really... it's just screwed
09:49imirkin_: joi: i gave up when i accidentally deleted all my wip changes
09:49imirkin_: but i wasn't getting far... deadlocking with my stupid mutexes
09:49imirkin_: because some functions are both public and private
09:49imirkin_: so this will all need some careful thought
09:49imirkin_: and for now my conclusion is "sorry, warsow doesn't work on nouveau"
09:50joi: warsow uses one context from multiple threads?
09:50imirkin_: no, it uses multiple contexts from multiple threads
09:50imirkin_: which is perfectly legal
09:50imirkin_: just unsupported by nouveau
09:50joi: so can we allocate separate channel for each context?
09:50imirkin_: sure, but that kills perf and is unnecessary for everything else
09:51imirkin_: we want to keep using a single channel.
09:51imirkin_: we could allocate separate pushbufs for each context, but even that's not particularly useful
09:51joi: anyone measured this?
09:51imirkin_: that hw context switches are slow? yeah, afaik
09:52imirkin_: i haven't personally though
09:52simulacr: what's the way to change fan speed? i think 1000 (sensors output) not enough because xorg freezes after some load with opengl video output in mpv or in some games, xv video output doesn't cause a freeze because more cpu-related afaik
09:53imirkin_: simulacr: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/thermal/nouveau_thermal
10:00joi: imirkin_: so the problem comes from nouveau not tracking state per context or not invalidating gl state of other contexts?
10:01imirkin_: joi: not at all
10:01imirkin_: joi: in fact that part works great :)
10:01imirkin_: joi: it comes from not locking access to the gpu from multiple concurrent e.g. draws
10:01imirkin_: or... other things, like buffer uploads
10:01imirkin_: can't really do one of those in the middle of a draw
10:02imirkin_: because of how the kick handler works
10:02imirkin_: and also other reasons like you can't do random stuff between begin/end
10:02simulacr: imirkin_: this is it, thanks
10:03imirkin_: joi: i'll get back to it eventually, but it's not a simple task
10:03imirkin_: joi: you want to do the locking logically and not slow down the average case
10:03imirkin_: (average case = single thread doing things at any given time)
10:24joi: found a workaround :)
10:24joi: ./warsow +set r_multithreading 0
10:25imirkin_: joi: ah excellent. problem solved ;)
10:25joi: yeah ;)
10:26imirkin_: i figured there'd be something like that
10:27imirkin_: glad you found it
10:27joi: it's undocumented
10:29joi: I found it by "strings */* | grep thread"
10:42Tom^: karolherbst: ive been in stockholm, :<
10:46joi: heh, I'm sooo lucky - 2 crashes in reservation_object_wait_timeout_rcu in 20 minutes
10:48karolherbst: Tom^: no worries :)
10:48imirkin_: joi: that sucks... out of my domain unfortunately. make some logs for skeggsb ?
10:49karolherbst: Tom^: could you try out my stable_kepler_reclocking branch on your card without any other modifications?
10:49Tom^: probably can tomorrow, gonna hit the hay. been on a course and flown airplane back home and just got home so a bit tired :P
10:54joi: imirkin_, skeggsb: http://paste.ubuntu.com/13627889/
10:56karolherbst: joi: did you build nouveau yourself?
10:59joi: ... and third one happened 10 seconds after I posted above link ...
11:01joi: karolherbst: yeah, it happened on kernel 4.2 with drm-next from some time ago and your gddr5 patch
11:02karolherbst: mhh, maybe you could bisect it then?
11:02karolherbst: will be time consuming though :/
11:02karolherbst: or do you mean with some time ago, just with no obvious reason?
11:02joi: IIRC it was crashing before
11:54pmoreau: karolherbst: Great! I'll have a look at it. :-)
12:13karolherbst: pmoreau: nice thanks
13:12ravior: Does someone knows if there is someone currently looking at this? https://bugs.freedesktop.org/show_bug.cgi?id=92961
13:13imirkin_: ravior: not aware of anyone
13:14ravior: The GPU that is observed on is usually the only graphic chip mounted to some Dell business laptops.
13:15karolherbst: ravior: maybe you want to use either nvidia or nouveau
13:15karolherbst: but not both
13:15ravior: imirkin_: Thanks for the reply. I wanted to see if I can help with the debugging of this problem.
13:16ravior: karolherbst: I'm just using the nouveau driver. I don't have the proprietary driver installed.
13:16karolherbst: ahh okay
13:16ravior: The proprietary driver behaves strange on my machine + combined with a latest bug in the kernel, makes it unusable
13:17karolherbst: ravior: which is the latest version of nouveau you tried?
13:17karolherbst: there is always the chance, that newer software magically solves issues ;)
13:17karolherbst: not the ddx
13:18ravior: I've tried the latest testing driver from the Arch testing repository.
13:19karolherbst: imirkin_: this issue is basically nouveau got an unknown interrupt and doesn't know what to do, right?
13:19ravior: I've tried some downgrades to xorg/libdrm/xorg/kernel/mesa/nouveau, but this problem happened as far as july of 2015
13:20imirkin_: karolherbst: haven't the faintest clue
13:20ravior: I went as far as february with no results, but after that point I should have downgraded everything, so I stoped
13:20ravior: I can try to provide some logs, if it helps
13:21ravior: I've tried rising the drm log level from the kernel, but the messages didn't helped
13:21karolherbst: imirkin_: I meant this: https://bugs.freedesktop.org/attachment.cgi?id=103307 last few lines
13:21karolherbst: ravior: nouveau.debug
13:21karolherbst: ravior: http://nouveau.freedesktop.org/wiki/KernelModuleParameters/
13:22imirkin_: ravior: you sure you have that issue? the original person who filed it was on a GT215
13:22imirkin_: you appear to be on a GF119 which is an extremely different gpu
13:22imirkin_: in order to say "yes, i have the same bug" that means that you understand the other person's bug, your bug, and have concluded that they are the same
13:23ravior: imirkin_: GF119M [NVS 4200M]
13:23imirkin_: if the issue is "desktop freezes", that can happen for a million different reasons
13:23ravior: I've attached the Xorg log in the ticket mentioned above
13:23imirkin_: all that'll have is "xorg froze. XORG FROZE! OH NOOOO XORG FROZE"
13:24karolherbst: I proudle quote from the xorg.log: "(EE) [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack."
13:24karolherbst: and so on
13:24karolherbst: basically I don't think the xorg tells us much
13:24ravior: imirkin_: The Xorg log and dmesg messages before the log are in https://bugs.freedesktop.org/show_bug.cgi?id=71659
13:24imirkin_: it's a side-effect of the gpu hanging
13:25pmoreau: karolherbst: Don't you need to do some capping for `boost_mode == 3`? Or are we retrieving the data directly from VBIOS and everything is fine?
13:25imirkin_: ravior: where's your dmesg?
13:25imirkin_: i don't see it
13:25karolherbst: pmoreau: boost_mode > 2 basically means no clamping of the highest clock available
13:25karolherbst: pmoreau: I mean, we could parse this and say "4" is not a valid number
13:26karolherbst: but then again, I could also just use keywords
13:26karolherbst: you can also tell gcc to do -O6
13:26karolherbst: but then again, it is the same as -O3
13:26ravior: imirkin_: I'm sorry. I haven't attached the full dmesg log on the ticket. I've posted only the errors seen on the dmesg generated by nouveau before the freeze
13:26pmoreau: "4V might be too much, please use something somewhat smaller"
13:27karolherbst: pmoreau: anyway I think we are slowly getting there
13:27ravior: The rest of the dmesg seemed clean. I'll attach the full dmesg log if it will help the debug effort.
13:28karolherbst: pmoreau: I got mupufs kepler card to crash under nvidia, just because I raised the "boost_max_voltage"
13:28karolherbst: so maybe if we stick to that value, all kepler cards run stable at such a clock then
13:28pmoreau: karolherbst: It's more that you say "3: boost to max clock available (still limited by gpu and boost voltage)", and I was wondering how the "limited by gpu and boost voltage" was applied
13:28karolherbst: pmoreau: https://github.com/karolherbst/nouveau/commit/db2aab7af61741d57fa9039f8a1f4aa687256b82 and https://github.com/karolherbst/nouveau/commit/07c51b807bfdab306c47c264278d65d4ccf2f4ed
13:29karolherbst: the idea is simple: if a cstate wants a voltage higher than the card supports: drop it
13:29karolherbst: if a cstate wants a voltage higher than the max boost voltage: drop it
13:29pmoreau: Ah! It was in the previous patches… :-D
13:29pmoreau: I should have looked backwards
13:29karolherbst: these are things we want to do anyway
13:30karolherbst: regardless whether we support dyn reclocks and boosting and all that stuff
13:30karolherbst: we shouldn't go beyond these voltages
13:30karolherbst: this is OC domain
13:32pmoreau: Could have been nice to have some more hints at what had changed in the v2: you had a v2 comment in one of the patch, but not in other ones you modified, nor in the ones you added.
13:32pmoreau: But it's a minor thing since the commits are small enough
13:36karolherbst: pmoreau: ohh right, I have to do that cleaner :)
13:36karolherbst: pmoreau: basically I improved "clk: allow boosting only when NvBoost is set " and added that boost_max_voltage thingy
13:38karolherbst: ohh I think I done something wrong there :/
13:38karolherbst: or maybe not
13:39hakzsam: imirkin_, right, your way to implement emitMEMBAR() is much better :)
13:39imirkin_: hakzsam: i've had practice :)
13:42karolherbst: pmoreau: the bad thing about most of these patches are is, that I can't test them myself :/ all my cstates have voltages attached lower than what the boost_max_voltage and the pwm max voltage says :/
13:42pmoreau: karolherbst: Looks like hakzsam doesn't want to right v2 message as well :p
13:43hakzsam: pmoreau, I was lazy yeah :)
13:44karolherbst: pmoreau: I have hard time to get what your sentence should mean :/ sorry
13:45pmoreau: karolherbst: s/right/write
13:45hakzsam: s/right/write I guess
13:45pmoreau: Getting tired… --"
13:45karolherbst: now it makes sense
13:45karolherbst: usually I write them though
13:51karolherbst: mhh maybe I will get the blob driver to go above the tdp on my gpu :/
13:51karolherbst: sounds tricky though
13:56karolherbst: how do I do some vdpau video playback again?
14:01imirkin_: karolherbst: mplayer -vo vdpau
14:01imirkin_: karolherbst: iirc DRI3 support patches landed very recently for it, i haven't tried it myself though
14:01imirkin_: karolherbst: should be apparent what's going on when you do vdpauinfo... might have to force VDPAU_DRIVER=nouveau
14:01karolherbst: nah, I want to run it on the blob
14:01karolherbst: to max out power consumption
14:02karolherbst: yeah well :/
14:03karolherbst: core 100%, video 100%, memory 22%, pcie 18%
14:03karolherbst: still only 56W :/
14:04karolherbst: then I have to mess with the pwm myself
14:06karolherbst: nope, gpu is getting too hot
14:06karolherbst: already at 80°C at only 60W
14:06karolherbst: and TDP is 80W
14:19ravior_: imirkin_, I've attached the dmesg log for the freeze in: https://bugs.freedesktop.org/show_bug.cgi?id=71659
14:19imirkin_: ravior_: i don't suppose kernel 4.3 or 4.4-rc3 helps?
14:20ravior_: imirkin_, I can't update the kernel because of: https://bugs.archlinux.org/task/46894
14:43karolherbst: mupuf: will nvafakebios work if the memory are is at 0xa007b300 ?
14:44karolherbst: or is it too high
15:47ravior_: imirkin_, If I can provide more debug info for this problem, just leave a note on the ticket. I'll respond as soon as possible. Thanks for listening in.
15:48imirkin_: ravior_: sorry i'm not much help... but i'm just largely unfamiliar with the issues at hand
15:51Arbition: Hi, I have a GK208M, and am running on fedora rawhide kernels, would I be getting nouveau patches close to release?
15:51Arbition: just updated to kernel 4.4.0-0.rc3.git1.1
15:52imirkin_: Arbition: can you rephrase your question? not sure i understand...
15:52ravior_: Nothing to be sorry about:). I just wanted to highlight this problem. It bothers me that I can't evade it without more or less breaking my system.
15:52Arbition: Well I saw http://lists.freedesktop.org/archives/nouveau/2015-December/023442.html and am wondering when that will be available in the main kernel tree
15:53imirkin_: Arbition: not for another 3 months or so, in all likelihood
15:53Arbition: not even in linux-next?
15:53imirkin_: skeggsb is bad about sending stuff up early to drm-next, so... no
15:53karolherbst: maybe we could squeeze that in for 4.5, but I wouldn't feel good about that without proper testing, so 4.6
15:54karolherbst: don't expect it earlier than 4.6 ;)
15:54karolherbst: but you can try it out if you want though :p
15:54Arbition: karolherbst: as you were the one posting that patch, what chipsets were you able to test it on?
15:54karolherbst: don't think it makes much sense for your gpu though
15:54karolherbst: Arbition: gk106
15:55imirkin_: Arbition: fwiw your GK208 is unlikely to benefit much from karol's work... you probably have DDR3 vram?
15:55karolherbst: I don't think they are needed for GK208M actually, because they don't volt too high
15:55Arbition: ah ok
15:55karolherbst: Arbition: are there any issues with your kepler card with 4.4?
15:55imirkin_: Arbition: i'd guess everything already works for you... except the pcie stuff
15:55Arbition: Well I'm not so sure
15:56imirkin_: pastebin dmesg
15:56karolherbst: Arbition: are you able to reclock to max perf state without messing up?
15:56Arbition: no, I set to 0a but only got base and then I was unable to change it again, or sudo for some reason
15:57karolherbst: yeah then we need dmesg
15:57Arbition: Give me a summary of what logs to give and I will try it again
15:57Arbition: just dmesg?
15:57Arbition: so just add nouveau.pstate=1 to the kernel, or should I add other options?
15:58karolherbst: its fine
15:58Arbition: alright, trying now
15:59karolherbst: imirkin_: seems like all mobile gk208 are ddr3
16:00imirkin_: not just the mobile ones... i think some are gddr5 though
16:00karolherbst: imirkin_: the 740M has a gddr5 variant, but thats gk10x again
16:01karolherbst: ohh gt 640 rev 2 and gt 730 (gddr5) are gddr5 gk208
16:01karolherbst: and the quadro ones
16:02Arbition: This is an optimus 730M
16:02Arbition: thats all I could say about it
16:02imirkin_: ohhhh i should have run http://cgit.freedesktop.org/mesa/mesa/commit/?id=52a800a687ee68483fe7cd83b137630b74e2127b through shader-db
16:02imirkin_: oh well. next time.
16:05Arbition: I seem to be getting stack traces
16:05karolherbst: 730M seems to be ddr3 only then
16:05karolherbst: ohh nice
16:05karolherbst: show us :p
16:05karolherbst: and please full dmesg
16:05imirkin_: Arbition: perhaps the gpu is off when you're trying to reclock?
16:05imirkin_: that might be an issue
16:05karolherbst: ohhh wait
16:05karolherbst: this is an issue
16:05Arbition: yeah it knows its supposed to go into 0f, but its not active
16:06karolherbst: this might help: https://github.com/karolherbst/nouveau/commit/e52f60b00010700fba1839c62d622e34879ee1a4
16:06karolherbst: Arbition: try to reclock while something runs on the nvidia gpu
16:06Arbition: hmm, not really sure how to do that
16:07Arbition: any examples?
16:07karolherbst: Arbition: start any gl application from command line with DRI_PRIME=1 in front of that
16:07karolherbst: ohhh wait
16:07karolherbst: for that optimus has to work
16:07karolherbst: try this: DRI_PRIME=1 glxinfo | grep "OpenGL vendor string"
16:07karolherbst: what is the output?
16:08Arbition: interesting, I think gtk3 applications were not working until I executed that, but the command itself still hasn't returned
16:08Arbition: base is now active though, but not the requested pstate
16:09Arbition: ok now my laptop has locked up
16:10karolherbst: yeah, I think this also happened for me, after trying to mess with the pstate while the gpu is off
16:10karolherbst: Arbition: boot with nouveau.runpm=0
16:10imirkin_: Arbition: moral of the story: don't futz with the gpu while the gpu is off
16:10karolherbst: in that case the gpu won't turn off
16:10karolherbst: imirkin_: the patch looks good though, doesn't it?
16:11imirkin_: karolherbst: dunno maybe? get skeggsb to look at it
16:11imirkin_: skeggsb: there are like a million patches waiting on you... please try to process them :)
16:12Arbition: Hmm, interesting, running without pm has also fixed some other issues which aren't graphically related
16:12karolherbst: for example?
16:13Arbition: after logging in, the display manager refuses to do anything for about 30 seconds, even though I run xmonad
16:13karolherbst: ohh yeah
16:13Arbition: vts would also not show up for about the same time if I switched to one
16:13karolherbst: nouveau is funny sometimes, or the X server
16:13karolherbst: ohhhh wait
16:14karolherbst: there is this issue in one library
16:14karolherbst: which was it again
16:14karolherbst: right libpcieaccess
16:15Arbition: ok so I echoed 0f into pstate, but as before, the command doesn't return, yet the output changes to indicate it knows the target pstate
16:16karolherbst: dmesg please
16:16Arbition: glxinfo also isn't returning
16:16Arbition: oh wait, it just did, partially
16:16karolherbst: it hangs before printing memory
16:16karolherbst: after "Accelerated: yes"=
16:17Arbition: I don't know, as I grepped
16:17karolherbst: then without grep
16:17Arbition: if I try it again, it'll probably hang like last time, I'm going to upload dmesg first
16:19Arbition: well I would paste it, but dmesg only seems to return line after line of "nouveau 0000:01:00.0: fifo: CHSW_ERROR 00000002"
16:19karolherbst: something is really messed up then
16:19Arbition: glxinfo finally returned
16:20karolherbst: Arbition: could you reboot and then dmesg without doing anything?
16:21Arbition: well having just run glxinfo, at the moment the last thing its returned is a table of "64 GLXFBConfigs"
16:21Arbition: but just as I executed the command, hang
16:23Arbition: just waiting to get in
16:25karolherbst: Arbition: okay, but you still don't have nouveau.pstate=1 in your kernel ;)
16:25karolherbst: but yeah
16:25karolherbst: this thing with waking up the gpu all the time is a known issue
16:25Arbition: oh, thought you asked for no changes
16:25karolherbst: I meant no changes in no commands on the gpu and stuff
16:26karolherbst: but you could try this out:
16:26karolherbst: run lspci
16:26karolherbst: it should also hang a while
16:26Arbition: returned almost immediately
16:26karolherbst: well almost or like 1 second later?
16:26Arbition: 1 second I guess
16:26Arbition: second time, less than
16:26karolherbst: then the gpu was woken up ;)
16:26karolherbst: for the second run the gpu is still on
16:27karolherbst: if you wait 5 seconds between runs, it will wait again
16:27karolherbst: same with glxinfo
16:27Arbition: just tried again, less than one second
16:27Arbition: barely perceptable
16:27Arbition: maybe 200ms
16:27karolherbst: glxinfo should wait for a bit after "Accelerated: yes"
16:27Arbition: hang on
16:28Arbition: with DRI_PRIME=1 or without?
16:28Arbition: no, didn't hang on anything
16:28karolherbst: mhh okay
16:28karolherbst: maybe this is an fixed issue by now or something
16:29Arbition: not seeing any nouveau in glx info, even though I ran lspci the second prior
16:29karolherbst: then boot again with nouveau.runpm=0 nouveau.pstate=1
16:31Arbition: ok so I turned off runpm, but running glxinfo off the bat still shows intel graphics
16:33karolherbst: okay, now output of DRI_PRIME=1 glxinfo | grep "OpenGL vendor string"
16:34Arbition: returns nouveau immediately
16:34karolherbst: okay, nice
16:34karolherbst: now try to reclock to max perf level
16:35Arbition: just to double check, this is the correct command to do so echo "0f" > /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/pstate
16:35Arbition: I did a find /sys -iname pstate to find it
16:36karolherbst: should work
16:36karolherbst: though you also find it in /sys/class/drm/card1/device/pstate ;)
16:36Arbition: actually... its on card0 for me
16:36Arbition: i'm pretty sure
16:37karolherbst: card0 should be intel
16:37Arbition: no card1 is intel for me
16:37Arbition: anyway, put 0f into pstate, and the command isn't returning
16:38Arbition: nothing from the past 2 minutes in dmesg
16:38karolherbst: something is odd
16:38karolherbst: then this
16:39Arbition: oh wait
16:39Arbition: there was something from earlier, possibly from when I ran glxinfo
16:40karolherbst: upload this file somewhere /sys/kernel/debug/dri/0/vbios.rom
16:40karolherbst: you might have to cat it into /tmp or somewhere before being able to upload it
16:40Arbition: well here is another dmesg anyway https://dpaste.de/vYZd
16:41karolherbst: this doesn't look too good
16:41Arbition: tell me doc, whats the prognosis
16:42karolherbst: no idea
16:42Arbition: ok I'll upload the vbios
16:42karolherbst: just that it isn't caused by nouveau
16:42karolherbst: most likely
16:42karolherbst: maybe it is
16:42karolherbst: who knows
16:45Arbition: does nouveau use shm at all?
16:45karolherbst: no clue
16:46Arbition: /dev/shm that is
16:46imirkin: for what?
16:46imirkin: not explicitly...
16:46Arbition: wait, nevermind
16:46Arbition: just remembered thats a userspace issue
16:46karolherbst: imirkin: any idea about this locking issue?
16:46imirkin: karolherbst: if it's about the kernel, i have no idea
16:47karolherbst: something dma buf related :/
16:47karolherbst: imirkin: but this nvidia card is also card0 in debugfs
16:47karolherbst: really weird
16:47imirkin: why is that odd?
16:47imirkin: driver load order is wtvr
16:48karolherbst: ohhh okay
16:48Arbition: if it is at all useful given you've noticed stuff, vbios https://drive.google.com/file/d/0B2jHgkGt14XJQnZVVm53SG1Dbk0/view?usp=sharing
16:48karolherbst: maybe, maybe not
16:49Arbition: :| reboot locking up again
16:50Arbition: So is there any other information I can get?
16:50Arbition: or deliver
16:50karolherbst: hard to tell
16:51karolherbst: Arbition: does this "[ INFO: possible circular locking dependency detected ]" issue appears again?
16:51Arbition: under what conditions?
16:51karolherbst: running something with DRI_PRIME=1
16:52Arbition: Well I just rebooted without runpm=0 and pstate=1
16:53karolherbst: what does DRI_PRIME=1 glxgears do?
16:53Arbition: ah well I just did it with glxinfo and it did show up again
16:54Arbition: glxgears works, but it doesn't cause it to show up again
16:57Arbition: curious, 45 seconds after running glxgears, I'm seeing "DMA-API: debugging out of memory - disabling"
16:57karolherbst: Arbition: do you mind sending this snippet: https://gist.githubusercontent.com/karolherbst/cd8292689959417a0111/raw/d5837b96ff56ec72a36ab12519dcbbd815be1d86/gistfile1.txt to firstname.lastname@example.org ?
16:57Arbition: um, I've never posted to a mailing list before
16:58karolherbst: and write under which circumstances you can reproduce this issue
16:58karolherbst: Arbition: text only, no html ;)
16:58karolherbst: and subscripe to the ML before
16:58karolherbst: that's it :p
16:58karolherbst: it is better that you are the contact person, because I wouldn't be able to help there
16:58Arbition: oh... I use gmail, I'm not 100% sure I can send text only (no html) I think I may have seen the option to switch it off, but I'm not sure
16:58karolherbst: should be possible
16:58Arbition: ah I see
16:59Arbition: so how do I subscribe to the list?
16:59karolherbst: Arbition: http://lists.freedesktop.org/mailman/listinfo/dri-devel
17:00karolherbst: Arbition: you will get the message from the ML though, so you might want to bundle them ;)
17:01karolherbst: "Would you like to receive list mail batched in a daily digest?" -> yes
17:01Arbition: oh I was going to leave it as no, thinking it meant, get none >.< thanks for the tip
17:03karolherbst: Arbition: I am sure your other nouveau issues might be somewhat related to that locking issue
17:03Arbition: could be
17:09imirkin: RSpliet: congrats -- found another bug in the nv50 mad stuff ;)
17:09imirkin: RSpliet: it's just the feature that keeps on giving
17:09imirkin: admittedly it's only triggered when there's a constant folding fail... but... heh
17:10imirkin: [i mean seriously, who does mad(0.0, 0.0, val)
17:10imirkin: but apparently our const folding doesn't handle that? very odd...
17:12karolherbst: Arbition: but as it seems, my patches may help your gpu, but only when this locking issue is fixed :/
17:13Arbition: I posted to the list
17:13karolherbst: yeah, saw it
17:13Arbition: I'm a little concerned most posts have something in [...] while mine does not
17:13karolherbst: ? what do you mean?
17:13Arbition: in the subject
17:14karolherbst: doesn't really matter thought
17:15karolherbst: maybe you should have choosen a more "news articke" like subject, like: "deadlock while using DRI_PRIME" :p
17:15Arbition: I'm also curious what they'll say about my kernel taint line. G and W don't look particularly problematic...
17:16karolherbst: usually nothing
17:20karolherbst: but besides that it somehow seems to work though, I mean, maybe this deadlockijg scenario is just rare and everything
17:20Arbition: well I repeated it?
17:21karolherbst: yeah don't know acutally, did DRI_PRIME=1 glxgears run fine?
17:21Arbition: I suspect it only happens once per boot
17:21karolherbst: well it is more an info about a deadlock I guess
17:21karolherbst: than the actualy deadlock
17:21karolherbst: would be still bad if that would trigger
17:21karolherbst: but you said an echo into pstate also locked the call?
17:22karolherbst: do you want to cat the pstate file?
17:22Arbition: Everytime I echoed into pstate it locked, yes
17:22Arbition: but the contents of the pstate node did change to (indicated with a *) the targeted pstate
17:22karolherbst: I hope you still boot with nouveau.runpm=0?
17:23Arbition: but AC: remained on base
17:23karolherbst: okay, then we need that stack of the process
17:23Arbition: I think that lock occured both with and without runpm=0
17:24karolherbst: yeah, doesn't matter now (the lock). I am more concerned why the echo into pstate blocks
17:24karolherbst: there is something really fishy going on
17:24Arbition: restarting with pstate and runpm
17:24Arbition: yes that behaviour also occurs regardless of runpm
17:25karolherbst: in the blocking shell
17:25karolherbst: try to terminate the echo call with ctrl+c
17:25Arbition: Already tried, does nothing
17:25karolherbst: it should print ^C
17:25karolherbst: do you have htop installed?
17:25karolherbst: open it in another shell ;)
17:25karolherbst: press F4
17:25karolherbst: type in bash
17:26Arbition: hang on, let me do the pstate switch first
17:27Arbition: huh, nV is on card1 now
17:27karolherbst: as imirkin said: load order
17:27karolherbst: might change
17:27karolherbst: depending on stuff in the kernel
17:27Arbition: ok command ran, ctrl+c did nothing, running htop
17:27Arbition: no excess CPU load
17:28karolherbst: doesn't matter
17:28karolherbst: this should only display bash commands then
17:28karolherbst: one of them should have a "D" in the S coloumn
17:28Arbition: Yep, thats also the evelated privelage one
17:28karolherbst: we need its PID
17:29karolherbst: go into /proc/PID_here
17:29karolherbst: and cat the stack file
17:29karolherbst: I need this :D
17:31Arbition: This should be it https://drive.google.com/file/d/0B2jHgkGt14XJTW5PbV9LQkFKV2M/view?usp=sharing
17:31karolherbst: looks about right
17:32karolherbst: ohh okay
17:32karolherbst: Arbition: htop again
17:32karolherbst: Display options
17:32karolherbst: unselect Hide kernel threads
17:33karolherbst: one of them should be "D"
17:33Arbition: yes, only one
17:33karolherbst: stack of this one then ;) you know the drill
17:33imirkin: neat. so for nv50, my "use $r63 instead of 0" change had this effect over a large-ish shader-db: http://hastebin.com/ugaguqebay.coffee
17:33karolherbst: imirkin: nice :D
17:34imirkin: surprising that so many programs were hurt... oh well
17:34karolherbst: yeah, but why does it help at all? :/
17:34karolherbst: I can't figure why
17:34imirkin: because registers can go anywhere
17:34imirkin: whereas immediates can't
17:35imirkin: also immediates force 8-byte instructions, while registers often fit into 4-byte instructions
17:35karolherbst: the pmu messed up
17:35Arbition: I guess thats card switching for you >.>
17:36Arbition: idk maybe lenovo is agressive with its pm?
17:36imirkin: i guess i should make my script print *which* ones were hurt
17:36karolherbst: nvidia gpus have multiple little co processors on it
17:36karolherbst: called "falcons"
17:36karolherbst: and the pmu is one of them
17:36karolherbst: what basically happens is this: your kernel sends a request to one of them and waits for a reply
17:36karolherbst: but doesn't get one
17:36karolherbst: and now it just waits forever
17:37karolherbst: I might have a fix for this already
17:37karolherbst: I also got such issues
17:37karolherbst: but more like 1 in 20.000 requests
17:38karolherbst: Arbition: this patch might help here: https://github.com/karolherbst/nouveau/commit/f159e2910b44c52b89b6512d1213be5d02bdafd9
17:38Arbition: so might be a while before this makes its way to release candidate kernels
17:39karolherbst: I have to know if that helps you
17:39karolherbst: which means you need to compile nouveau yourself :p
17:39Arbition: Guess I'll have to tool up
17:39Arbition: to build a kernel
17:39karolherbst: yeah, but I won't be able to do that tonight
17:39Arbition: now isn't a good time though
17:39karolherbst: it is already 2:40 am here
17:39Arbition: yeah, I was thinking, Germany, would be late
17:41karolherbst: but it bothers me why this issue tirggers for you like always :/
17:41karolherbst: this has all kinds of side effects and stuff
17:42karolherbst: I wrote that with the fact, that this happens mabe once an hour in normal unstable load use case (with dynamic reclocking) in mind, but not if that triggers like every time :/
17:43karolherbst: Arbition: could you install envytools?
17:43karolherbst: I just want to confirm it is the issue I am thinking off
17:45karolherbst: as root:
17:46karolherbst: nvapeek 0x10a4cc
17:46karolherbst: nvapeek 0x10a4c8
17:46karolherbst: output of both please
17:46Arbition: before or after trying to change pstate?
17:46karolherbst: it has to lock
17:47Arbition: both 00000001
17:48karolherbst: that's odd
17:50karolherbst: I am not that good with the pmu though :/
17:51karolherbst: lets mess stuff up
17:52karolherbst: Arbition: nvapoke 0x10a4c8 0x2
17:52karolherbst: did the echo call return?
17:53karolherbst: nvapeek 0x10a4c8 0x8
17:53Arbition: 0010a4c8: 00000002 00000001
17:54karolherbst: something strange is going on, really
17:54karolherbst: no idea know
17:54karolherbst: but we can figure out something tomorrow, but I am not that good in that area, yet
17:55karolherbst: will go to bed now
17:56Arbition: ok sleep well
21:02gnurou: hey everyone - how are files like Mesa's nv50_texture.xml.h generated from rnndb? I cannot find any rule to build it in either envytools or mesa...
21:43skeggsb: gnurou: from rnndb/, execute "../rnn/headergen graph/g80_3d.xml" (etc)
22:00gnurou: skeggsb: uh, nice, thanks! I couldn't find a nv50_texture.xml in rnndb, so I suppose the name has changed
22:02gnurou: skeggsb: finally got textures to (mostly) work with GM2 thanks to help from ahuillet, it turned out to be the texture headers that have completely changed for Maxwell and old headers got obsoleted starting from GM2
22:02gnurou: now I'm seeing whether I can get permission to release the texture header doc to rnndb...
22:05gnurou: skeggsb: of course I know this makes little sense if firmware loading doesn't work, but the other good news is that I finally got a debug card and can work on dGPU support for secure boot