09:44 pmoreau: RSpliet: Out of the GTxxx, I only have one GT200. :-/
09:46 RSpliet: pmoreau: fair
09:46 RSpliet: oh that's the one coupled with an MCP79 right?
09:46 RSpliet: anyway, no PMU, so I'll go and swap GPUs later today I guess
09:48 pmoreau: No, it is a G96 which is coupled with the MCP79. The GT200 is a regular desktop GPU.
09:50 RSpliet: ah yes... somehow after I said it it sounded like an odd combo to me :-)
09:52 pmoreau: ;-)
11:30 karolherbst: mupuf: mhhh, something is really odd
11:30 karolherbst: while X isn't running, nvidia-smi basically returns garbage for the power consumption
11:37 gregory38: hello
11:37 karolherbst: gregory38: hi
11:38 gregory38: may I bother you 5 minutes on a wayland topic question
11:38 gregory38: now that Fedora is moving to wayland, people ask me native wayland support
11:38 gregory38: My code base got some xlib stuff in it
11:39 gregory38: do I need to port it to xcb ? or it isn't related ?
11:42 karolherbst: gregory38: mhh, well on wayland you can't use any x library except you are fine with xwayland
11:42 karolherbst: afaik
11:43 karolherbst: so xcb can't be used too
11:43 gregory38: ok, it was my understanding but I wasn't sure
11:43 karolherbst: I am not sure either anyway
11:44 karolherbst: the EGL situation is a bit silly on wayland, but I think you need to target some wayland EGL implementation and use native wayland things to create your windows and stuff
11:44 karolherbst: so, best is to use some abstraction for this
11:45 gregory38: yes, I guess the best move will be to move all the old code to recent toolkit
11:45 gregory38: so far I have a patchwork of wxWidget/Gtk/xlib/sdl ....
11:46 gregory38: Thanks for the feedback :)
11:46 karolherbst: well, maybe you should choose one :p
11:46 karolherbst: did you port over to EGL already?
11:47 gregory38: I have some EGL code to replace GLX
11:47 gregory38: it is quite old
11:47 karolherbst: well
11:47 karolherbst: you can't use GLX on pure wayland
11:47 karolherbst: so you might want to port over to EGL first
11:47 gregory38: I just understood yesterday that my current Nvidia driver doesn't support openGL over EGL
11:47 karolherbst: they do though
11:47 karolherbst: just need to update ,)
11:47 gregory38: Yes
11:48 gregory38: but I'm on Debian Jessie
11:48 karolherbst: :D
11:48 karolherbst: well
11:48 gregory38: and new package got plenty of new lib/modules
11:48 karolherbst: sure
11:48 gregory38: I'm pretty sure it will explode with my old hack to switch driver on reboot
11:48 karolherbst: the situation with nvidia and wayland won't fly anyway
11:48 karolherbst: not yet at least
11:49 karolherbst: gregory38: you could also use the mesa sw renderer
11:49 gregory38: what do you mean ?
11:49 gregory38: sw renderer with Nvidia kernel ?
11:50 gregory38: Otherwise I can reboot to test nouveau
11:51 karolherbst: yeah, sw with nvidia kernel
11:51 gregory38: Hum, oh it will be very interesting
12:48 gregory38: karolherbst: thanks for the tip. I manage to start with my EGL code. However I need arb_buffer_storage so I hacked mesa to report it as supported.
12:49 karolherbst: mupuf: https://gist.github.com/karolherbst/bc0047983d0fbba1a44db68d4936f44b \o/
12:49 karolherbst: 250W -> 196W
12:49 karolherbst: gregory38: there is an env var for that
12:49 karolherbst: gregory38: MESA_EXTENSION_OVERRIDE
12:49 karolherbst: http://mesa3d.org/envvars.html
12:50 gregory38: oh great. Perfect :)
12:54 karolherbst: mupuf: it was the 150W/250W/265W entry though... which is odd, but meh
12:55 karolherbst: ohhh, it starts to make sense :)
13:09 karolherbst: mhh
13:09 karolherbst: odd
13:16 karolherbst: mhh the cap entry byte isn't set for all cards...
13:21 karolherbst: RSpliet: can you tell me what your gm107 reports as the power cap in nvidia-smi?
13:22 karolherbst: I doubt it will display anything power consumption related at all though
14:09 karolherbst: the titan caps at 862 MHz with furmark...
14:10 karolherbst: usually it runs at 1006MHz
14:31 karolherbst: \o/ I can detect the right power budget entry now
14:34 karolherbst: at laest on the titan
15:40 pmoreau: imirkin: If there is any need to further test the EXA? patches on GMxxx, I have my GM206 up and running.
15:40 imirkin: pmoreau: well, mupuf was getting segfaults
15:41 imirkin: pmoreau: so ... clearly additional changes are needed
15:41 imirkin: for some reason he wasn't getting a copy class created either
15:41 pmoreau: Ah, right
15:41 imirkin: although that in itself shouldn't be cause enough to be getting segfaults
15:42 imirkin: anyways, another tester wouldn't be so bad. gnurou also gave it a shot, but i don't think i have logs from his trials
15:42 imirkin: (to see whether he was getting a copy class or not)
15:53 pmoreau: Ok. I’ll have a try then
15:54 RSpliet: karolherbst: sorry, just read your message
15:54 RSpliet: I'll get back to you in ~30m to ask if you still need more info. Note that I don't have the blob on my laptop (gm107)
16:24 RSpliet: karolherbst: mind doing me a little favour?
16:25 RSpliet: ^ and see if you can make that work on Maxwell?
16:25 pmoreau: RSpliet: Do I need to run the blob?
16:26 RSpliet: pmoreau: I'm afraid so yes...
16:26 Moguri: Are there any docs/notes around current development/RE efforts around the GM200 cards (specifically GM204)? Also, what are current repos/branches for this work?
16:26 RSpliet: pmoreau: hopefully it's nothing more than changing the test on line 199 to include Maxwell/Pascal
16:26 RSpliet: but you never know
16:26 karolherbst: RSpliet: sorry, wasn't at my computer until now. Don't have access to a maxwell currently
16:26 RSpliet: karolherbst: Pascal is good too :-P
16:26 karolherbst: don't have one either
16:26 pmoreau: Eh eh eh!
16:26 karolherbst: Moguri: basically, nvidia screwed us here, so we can't do much RE on those
16:27 RSpliet: meh... well, next time you want to obtain the PMU firmware you can try fiddling with that tool for 10 minutes then and see where that gets you
16:27 karolherbst: Moguri: mmiotraces and mmts are the only thing we can do reliable
16:27 pmoreau: Ok, I’ll first have a try at Ilia’s patch, and then have a try at yours. :-)
16:27 karolherbst: RSpliet: it should be the same for 1st gen maxwell though
16:28 RSpliet: karolherbst: That's an assumption I might not want to make flat out before testing...
16:28 RSpliet: (but it does work wonders for Kepler)
16:28 Moguri: karolherbst: Yeah, that's unfortunate.
16:28 karolherbst: mupuf: I am done with the titan by the way, you can replace it with something else, maxwell2 maybe
16:29 karolherbst: RSpliet: right, usefull for porting over to nvidias interface and use it with nouveau
16:34 karolherbst: RSpliet: it seems like I got only garbage
16:34 imirkin: Moguri: is there a particular aspect you're interested in?
16:36 RSpliet: karolherbst: it's supposed to be garbage, it's your PMU firmware in binary format
16:36 Moguri: imirkin: Unfortunately, power managment, re-clocking, etc. Which, reading over the docs on the Nouveau site leads me to believe this is some of the trickier stuff (especially with GM200), and probably not a great first area to dabble in.
16:36 RSpliet: (not very nice to call it garbage to the handful of NVIDIA engineers who carefully assembled that firmware, but hey ;-))
16:36 karolherbst: RSpliet: it is still garbage
16:37 RSpliet: karolherbst. Tried running it through envydis -m fuc -V fuc5 ?
16:38 karolherbst: yeah
16:38 RSpliet: (and some flag to indicate the input is a binary instead of words)
16:38 karolherbst: isn't fuc5 kepler2?
16:38 RSpliet: idk, I just try them out randomly until one works
16:38 karolherbst: but fuc4 also produces garbage
16:38 karolherbst: and fuc3 as well
16:39 RSpliet: -i
16:39 RSpliet: ?
16:39 karolherbst: yeah
16:39 RSpliet: how odd... mind sharing the binary with me?
16:40 RSpliet: I finally have my mailserver back up
16:40 pmoreau: imirkin: I’m getting a "(EE) NOUVEAU: Failed to load module "fb" (module does not exist, 0)", "(EE) NOUVEAU(0): 1240:". I guess I am missing something, but not sure where this fb is supposed to come from.
16:40 pmoreau: RSpliet: \o/
16:43 imirkin: pmoreau: you pulled from my branch, yes?
16:43 imirkin: pmoreau: fb is an Xorg module afaik
16:43 karolherbst: RSpliet: might be that it isn't that much garbage, but well, it looks like it
16:43 pmoreau: Yes, I cloned from your repo, and since there was only one branch, I guess that should have worked
16:43 imirkin: pmoreau: yep.
16:44 imirkin: just wanted to make sure you weren't using stuff from the ML
16:44 imirkin: which has a number of issues
16:44 pmoreau: Ah, k
16:45 RSpliet: karolherbst: no that's garbage :-D
16:45 RSpliet: running the blob?
16:45 karolherbst: yes
16:45 RSpliet: which card?
16:45 karolherbst: gk106
16:45 imirkin: Moguri: well - first area to dabble in should be based on your interests
16:45 imirkin: Moguri: but yes, that's not one of the easier ones.
16:46 pmoreau: imirkin: Ah right, libfb.so. Hum… I guess something related to how I set up the paths in the Xorg conf
16:46 imirkin: pmoreau: you have to include the xorg path in ModulePath
16:46 imirkin: pmoreau: not just yours :)
16:46 imirkin: [i had the same issue]
16:46 karolherbst: Moguri: well, the missing things can be actually done with older cards as well
16:46 karolherbst: Moguri: reclocking isn't the problem on gm20x
16:46 karolherbst: it's done
16:46 karolherbst: pretty much
16:46 imirkin: pmoreau: http://hastebin.com/ilikopuwuh.nginx
16:47 RSpliet: karolherbst: okay thanks
16:47 imirkin: Moguri: the unfortunate bit is that without defeating the signature verification logic, we miss out on the ability to control a number of things from the PMU & co.
16:47 karolherbst: Moguri: if you have an older gpu, I could help you out with stuff, just on a gm20x you can't do much
16:47 RSpliet: odd, I just succesfully used this on a GK107, but it might be my older driver
16:48 pmoreau: imirkin: Yeah, I thought of it and added the system path as well, but I went all the way to drivers :-D
16:48 karolherbst: RSpliet: be aware that I have an optimus card
16:48 karolherbst: some things are odd there
16:48 karolherbst: RSpliet: like 0x619f04 isn't set automatically
16:49 RSpliet: karolherbst: right, but the basic mechanism of mapping a piece of sysram in the PMUs channel space should be similar
16:49 RSpliet: there might be some different decisions wrt. location of pagetables on optimus, so not ruling that out as a factor
16:49 karolherbst: RSpliet: I have to set 0x619f04 manucally, otherwise I can't fake the vbios
16:49 RSpliet: but could equally well be a driver mismatch
16:49 karolherbst: might be
16:49 Moguri: karolherbst: I have an older laptop laying around with a Fermi card (GT 425M, which I think was GF108). I could set that up as a dev/hacking environment. Then I don't risk destabilizing my main dev machine.
16:50 karolherbst: RSpliet: running 370.28
16:50 yoshimo: why would envytools fail to compile with http://pastebin.com/fw6dvmmA ?
16:50 imirkin: Moguri: def better to have a separate machine that you can crash ;)
16:50 karolherbst: yoshimo: cause you need gcc 6
16:51 karolherbst: Moguri: mhh, fermi has also some good things, depends on the vbios though
16:52 imirkin: Moguri: well, if you're interested in reclocking, fermi's reclocking logic is unfinished
16:52 pmoreau: imirkin: Seems to be working, weird…
16:52 imirkin: Moguri: RSpliet could probably help you get started on that
16:52 imirkin: pmoreau: cool. can you check your xorg log and see if it initialized COPY successfully?
16:53 pmoreau: I have a "(II) NOUVEAU(0): [COPY] async initialised"
16:53 Moguri: Okay, so I'll want to build Mesa and xf86-video-nouveau from the git repos listed on the main page of the Nouveau site. However, is there a different kernel and libdrm repo/branch I should use?
16:53 RSpliet: karolherbst: yeah, I have 325.27 I think
16:53 imirkin: pmoreau: pastebin the whole log just in case?
16:53 karolherbst: how old :O
16:53 karolherbst: that won't even compile on 4.8
16:53 RSpliet: I want it to properly support Tesla... kind of have to
16:54 imirkin: RSpliet: 340.x is the last version to support Tesla, fyi.
16:54 karolherbst: imirkin, Moguri: that is a nice task for gm20x though: https://trello.com/c/xk6T1MYa/164-port-16bit-table-offsets-to-32bit
16:54 karolherbst: has to be actually done to get reclocking working on a handful maxwell gpus
16:55 pmoreau: imirkin: http://hastebin.com/zazoqehupa.sql
16:55 karolherbst: Moguri: running nouveau currently?
16:55 RSpliet: imirkin: I know there's a few more recent versions, but there's no need to mess with this set-up now
16:55 Moguri: karolherbst: Both of the machines are currently running proprietary drivers.
16:56 karolherbst: k
16:56 karolherbst: well if you don'T mind get starting on some kernel hacking, this would be an important task
16:56 karolherbst: otherwise I will do it at some point...
16:56 karolherbst: but I say this for months already
16:56 imirkin: pmoreau: you have an AST chip?? this a server box or something?
16:57 pmoreau: I ended up with a server MB
16:57 yoshimo: karolherbst: thanks, looks like i have some updating to do
16:58 imirkin: pmoreau: if you don't mind just using it normally for a little while
16:58 imirkin: and seeing if you get any render artifacts or whatnot
16:58 mwk: yoshimo: actually, try adding -std=gnu++11
16:58 imirkin: that'd be awesome
16:58 mwk: to your CXXFLAGS
16:59 mwk: I think it should be supported by somewhat older gcc, gcc 6 just happens to have it as a default
16:59 pmoreau: imirkin: Will do! (the main advantage of this MB, is that I can plug in three GPUs, and have 2 full width PCIe slots)
16:59 pmoreau: imirkin: Good job!
17:00 mwk: actually, fuck it, I'll just add it globally
17:01 mwk: yoshimo: try updating and recompiling
17:01 imirkin: mupuf: sounds like it works for pmoreau as well. i'd appreciate it if you could debug things a bit on your end...
17:01 Moguri: karolherbst: Can that task be done/tested on GF108? If not, I may try to tackle it after I get more comfortable with nouveau dev on my laptop before messing with my main machine.
17:02 imirkin: Moguri: with GF108 the main thing left to do is reclocking ... RSpliet may have some advice if you're serious about attempting it.
17:02 imirkin: Moguri: otoh, there are a couple of Mesa-related tasks i could point you to if you wanted to mess with 3d things.
17:03 imirkin: [for fermi chips]
17:03 karolherbst: mwk: mind if I push https://github.com/envytools/envytools/pull/55 ?
17:03 karolherbst: mwk: gcc-5 doesn't support static_assert
17:04 karolherbst: it's a c++-17 feature anyway
17:04 karolherbst: or you add a message
17:04 karolherbst: then it's c++-11
17:04 mwk: karolherbst: go for it
17:04 mwk: huh
17:04 mwk: really?
17:04 karolherbst: mwk: http://en.cppreference.com/w/cpp/language/static_assert
17:04 karolherbst: ;)
17:04 karolherbst: yes
17:04 karolherbst: :D
17:05 karolherbst: so we should add , ""
17:05 karolherbst: then it's fine
17:05 mwk: what a piece of shit
17:06 karolherbst: nvbios is getting a bit ugly now though, but meh
17:06 mwk: karolherbst: it's always been ugly
17:06 mwk: I had a moment when I tried to make it less so, but it didn't last long
17:07 Moguri: imirkin: I do have interest in Mesa tasks, and I am familiar with OpenGL programming. Do you have a link with some information?
17:07 pmoreau: RSpliet: Ok, blob installed. What should I try to do now?
17:07 karolherbst: mwk: well, the scripts have 32bit addresses in front now
17:07 karolherbst: but we need this
17:07 karolherbst: also in the kernel
17:09 imirkin: Moguri: sec... writing it up now ;)
17:10 mwk: there, now it's C++11 compliant
17:10 imirkin: Moguri: https://trello.com/c/LGGIGvRe/167-fermi-add-support-for-32-samplers
17:10 karolherbst: :D
17:10 imirkin: Moguri: feel free to peruse that trello board as well, you don't have to do that one.
17:11 mwk: gods, I hope something will kill off C++ before 2033, maybe a meteor...
17:11 karolherbst: it has gotten a lot better with c++11 though
17:12 mwk: yeah, and it'll get even better with C++33, I'm sure
17:12 mwk: thing is, it's even more unlearnable now than in C++98
17:12 karolherbst: as always
17:12 karolherbst: mhhh
17:12 karolherbst: true
17:12 karolherbst: but you don't need to learn the old things
17:13 mwk: also, it's kind of what I've refered to in the commit message
17:22 yoshimo: mwk: compiled, you saved me from a time consuming system update ;)
17:23 yoshimo: brb
17:23 imirkin: Moguri: separately, there are a number of easy-ish features to be implemented in mesa for GM20x (also on that trello board)
17:32 pmoreau: Hum… I am getting a "WARN: Can’t probe 0000:03:00.0" as root on the GM206 using the blob. What did I forgot?
17:32 karolherbst: pmoreau: kernel argument
17:33 pmoreau: kernel argument?
17:33 pmoreau: Oh sorry, I forgot to say, this is when running `nvalist`
17:33 karolherbst: iomem=relaxed
17:34 pmoreau: Going to try that
17:35 RSpliet: pmoreau: sorry. That tool might be able to extract the PMU, but from the sound of karolherbst, it's unlikely to just work out of the box
17:36 karolherbst: RSpliet: let me try something
17:37 karolherbst: didn't work
17:37 pmoreau: RSpliet: "Register 0x10a110 not in order"
18:08 Yoshimo: nvagetpmu on a maxwellv2 says: Register 0x10a110 not in order , so far for the untested note in the commit message
18:12 karolherbst: Yoshimo: nvapeek that regiseter
18:13 karolherbst: pmoreau: you too
18:13 pmoreau: karolherbst: Will do
18:13 Yoshimo: aka sudo nvapeek 0x10a110 ?
18:13 karolherbst: Yoshimo: yes
18:14 Yoshimo: returns three dots
18:14 karolherbst: Yoshimo: would say it is kind of expected on maxwell2
18:14 pmoreau: Plain old zero
18:15 karolherbst: pmoreau: also 2nd gen maxwell?
18:15 pmoreau: GM206
18:15 karolherbst: k
18:15 karolherbst: expected then
18:15 karolherbst: cause the pmu code isn't uploaded this way anymore
18:15 karolherbst: the address is somewhere in the mmiotrace though
18:17 karolherbst: pmoreau: mind setting the tmp_reg to 7ffa2?
18:17 karolherbst: to get pass that error
18:17 karolherbst: allthough this won't be the right one
18:18 karolherbst: code is at 0x80000 and data at 0x80017
18:18 pmoreau: 7ffa2 is 1100badf FYI
18:19 karolherbst: no, I didn't mean to read from there
18:19 karolherbst: it's the value
18:19 karolherbst: but try 0x80000 instead
18:19 pmoreau: At which point should I set tmp_reg to 7ffa2, cause it is rewritten multiple times
18:19 karolherbst: line 212
18:19 karolherbst: and remove the if checks
18:19 karolherbst: the one
18:20 karolherbst: I am sure that 0x10a47c won't be helpfull either
18:20 pmoreau: 10a47c is zero as well
18:21 karolherbst: the channel isn't used at all, let me see
18:21 pmoreau: "Page directory entry invalid", with tmp_reg = 0x80000.
18:21 karolherbst: mhh
18:21 pmoreau: Peeking 0x80000 returns badf1100
18:22 karolherbst: it's the dma address
18:25 karolherbst: pmoreau: so basically this is what happens: nvidia writes that stuff into sysmen somewhere and tells the pmu the address where to look at.. code at 0x80000 and data at 0x80017.
18:27 karolherbst: ohhh
18:27 karolherbst: wait
18:27 karolherbst: try 0x7ffae
18:28 pmoreau: Still the page directory entry invalid
18:28 karolherbst: pmoreau: from a gm206 trace before the first pdaemon.data write: https://gist.github.com/karolherbst/1ad0a993b06b1b42236b9f436f98bbcc
18:29 karolherbst: yeah, cause the code can't handle that yet
18:30 karolherbst: try 0x704189c6 then
18:30 karolherbst: ohh, maybe
18:30 karolherbst: peek 0x10a480
18:31 pmoreau: 70277057
18:31 karolherbst: good
18:31 karolherbst: looks nice
18:31 karolherbst: instead of doing "mp_reg = peek(0x10a47c);", use 0x10a480
18:33 pmoreau: It does not crash, but the generated file is full of "0xff".
18:33 karolherbst: and instead of 10a110 it has to be 100cb8 >> 4
18:33 karolherbst: mhhh
18:33 karolherbst: maybe nvidia cleaned up
18:35 pmoreau: It should be `peek(0x100cb8 >> 4)`, or `peek(0x100cb8) >> 4`?
18:35 pmoreau: First option seems weird
18:35 karolherbst: it doesn't matter for the code
18:35 karolherbst: it's just reads it out and validates it
18:35 karolherbst: the other thing is important
18:36 mwk: wtf are you doing with 100cb8?
18:37 karolherbst: pmoreau: mind running that code inside a while true loop with the code gettng you 0xff and then load nvidia?
18:37 karolherbst: write into different files
18:37 karolherbst: and see if at one point the files differ
18:37 karolherbst: mwk: maxwell2 pmu code
18:37 karolherbst: mwk: see the gist link of mine
18:38 karolherbst: there nvidia sets up the gpu for reading the secured pmu image
18:38 karolherbst: some pmu things later
18:38 Yoshimo: pmoreau: which card are you currently trying?
18:38 pmoreau: GM206 still, so a 960
18:38 mwk: reading 100cb8 is a horrible idea
18:39 karolherbst: mwk: give us better ones
18:39 mwk: it's just the last flushed VM space
18:39 mwk: try 10a050
18:39 mwk: or 10a054
18:39 mwk: that should be the fake channel
18:39 karolherbst: wouldn't be surprised if they are 0 on gm206
18:39 Yoshimo: mwk: both are 70233e47
18:39 karolherbst: uhh
18:39 mwk: I wouldn't be surprised if the damn thing is encrypted one way or another
18:40 karolherbst: it isn't
18:40 pmoreau: peek(10a050) == peek(10a054) == 70277057
18:40 karolherbst: so the same as 0x10a480
18:40 mwk: and what does the channel contain around the vspace pointer?
18:40 mwk: does it look correct?
18:40 karolherbst: yeah
18:40 mwk: so why are you looking for a different channel?
18:42 karolherbst: mwk: what do you mean?
18:43 mwk: if it's correct, why are you looking at 100cb8?
18:43 karolherbst: because nvidia writes into that
18:44 karolherbst: but 100cb8 != 0x10a480
18:44 karolherbst: it doesn't actually matter for the code anyway
18:44 karolherbst: it is just there for validation
18:44 karolherbst: pmoreau: did you try that loop thing?
18:44 pmoreau: Was going to, but since there was some request for more info, I haven’t closed X yet.
18:45 karolherbst: k
18:45 karolherbst: you might want to do this inside tmpfs though
18:45 karolherbst: for speed ;)
18:50 pmoreau: How do you blacklist the blob? I thought something like modprobe.blacklist=nvidia would work, but apparently not
18:50 karolherbst: blacklist nvidia
18:50 karolherbst: but
18:50 pmoreau: I'll try with the file
18:50 karolherbst: if anything loads it, it gets loaded anyway
18:50 karolherbst: you want to do an alias to be sure
18:51 karolherbst: alias nvidia off
18:51 karolherbst: or something like that
18:59 pmoreau: Grrr… Don’t know why, I can’t manage to get a tty on screen… I can’t see the beginning of the boot messages, and then everything disappears
19:00 karolherbst: mhh
19:09 mwk: hey, someone here had issues with WoL on MCP7x, right?
19:10 karolherbst: that was me
19:10 karolherbst: why?
19:11 mwk: 'm trying to set it up for a few of my machnes
19:11 karolherbst: k
19:11 karolherbst: it's easy though
19:11 mwk: MCP73 works ok, MCP77 doesn't
19:11 karolherbst: you have 256 bit masks on the ethernet frame
19:11 karolherbst: and 6 slots for that
19:11 karolherbst: right, but linux wol support is crap anyway
19:12 mwk: *shrug* as long as I can enable the magic packet thing
19:12 karolherbst: uhh
19:12 karolherbst: magic packet
19:12 karolherbst: this should work already
19:12 mwk: yeah, that's what I expected
19:12 karolherbst: it worked on mine as well
19:13 mwk: hmm
19:13 mwk: nope
19:13 karolherbst: mhh, could you peek 218 and 21c?
19:13 mwk: "ethtool -s eth0 wol g", poweroff
19:14 mwk: then wol -v -i <mac> on another machine
19:14 mwk: MCP73 works, MCP77 does nopt
19:14 karolherbst: wait, 0x200 is the base for wol
19:14 karolherbst: yeah, could you should me what is inside 0x200 after you enabled g?
19:15 mwk: a moment, I need to get past the bullshit io mem protection
19:15 karolherbst: well
19:15 karolherbst: if you are lucky, you could get the phy mode working
19:15 karolherbst: but any ethernet broadcast would wake the machine up
19:16 mwk: that... would be a very bad idea
19:16 karolherbst: has the advantage that a ssh connection attempt would wake the machine up
19:16 karolherbst: but
19:16 karolherbst: you could also just hack in the frame masks and ignore this silly magic package thing
19:17 karolherbst: and let the machine wake up on any ssh connection attempt or if the source is spmething specific
19:19 karolherbst: mwk: the mcp77 isn't behind a router or something, just a plain hub between the machines, right?
19:20 mwk: a switch
19:20 karolherbst: should be fine I guess
19:20 mwk: the exact same switch as the MCP73
19:20 karolherbst: I see
19:21 karolherbst: 0x200 should be 0x01111 I think
19:21 mwk: I'm still trying to figure out how to access it
19:21 karolherbst: iomem=relaxed
19:22 karolherbst: mine was a mcp79 though, but I doubt that matters much
19:24 mwk: 00000200: 20001111 00000000 00000000 00000000
19:24 mwk: MCP77
19:24 mwk: same on MCP73
19:24 karolherbst: mhhh
19:25 karolherbst: poke 0x12000 into that
19:25 karolherbst: and see if it wakes up upon phyiscal activity
19:26 karolherbst: the upper bits are some kind of status
19:26 karolherbst: it's odd
19:26 mwk: MCP73 woke up quite soon after poweroff on some random packet
19:26 mwk: MCP77 didn't
19:26 karolherbst: mhhh
19:28 karolherbst: I doubt there is some kind of enable bit somewhere
19:28 mwk: hmm
19:28 mwk: I'll look for a bios setting...
19:29 karolherbst: uhh
19:29 karolherbst: that makes sense
19:30 karolherbst: mhh, I forgot which hashing algorithm was used for the pattern based things...
19:31 karolherbst: md4?
19:32 karolherbst: ohh wait, it was no hashing
19:32 karolherbst: but simply stupid block thing
19:32 karolherbst: ehm, not block thin
19:34 pmoreau: karolherbst: I’ll have to try that loop thing using ssh, cause I can’t see the TTYs…
19:34 mwk: yay
19:34 mwk: that was it
19:34 mwk: I had to enable "wake by PCI/PCIE device" in APM options...
19:35 karolherbst: makes sense
19:35 mwk: sorry for the noise :(
19:35 karolherbst: no problem
19:35 karolherbst: I still have to finish RE those bits
19:35 karolherbst: it's fun though
19:36 karolherbst: mwk: my idea was, to use pm_autosleep to let the machine go into suspend whenever it does nothing and use WOL to wake it up when I try to connect with ssh
19:36 karolherbst: so that I won't have to care about suspend/resume anymore
19:48 mooch2: hey mwk
19:48 mooch2: someone tested a vesa driver for nt on my riva tnt emulation
19:48 mooch2: apparently, it works fine
19:49 karolherbst: pmoreau: tell me if you get anything usefull :)
20:04 mwk: mooch2: sounds great!
20:04 mwk:is sketching plans for NV1 & NV3 PFIFO hwtests
20:04 mwk: that should happen soon-ish
20:05 mooch2: oh THANK GOD
20:20 jennifeiro: RSpliet: as you may had heard, if you follow this you get your gnome and cinnamon working, i can confirm that now http://askubuntu.com/questions/794529/amdgpu-pro-install-on-ubuntu-gnome-16-04-with-r9-285-and-rx-480
20:22 jennifeiro: though i used fglrx, amdgpupro works on/with the same userspace roughly, bug was in clutters cogl , luckily i did not have to debug it
20:25 jennifeiro: second thing you absolutey have to switch the xorg to 1.7 and maybe some kernel patches are also needed
20:33 jennifeiro: RSpliet: xorg has always worked so that, on debian for instance you fetch from the web an older xserver-xorg-core-1.7.1 and 1.7.2 are fine here, and unpack it with dpkg -x xorg.deb / do the same with the headers like xorg-dev.deb
20:33 jennifeiro: then fetch the source packages for xf86-input-evdev and synaptics and stuff, and recompile them
20:34 jennifeiro: it will do the trick
20:36 jennifeiro: apt-get install xorg-dev then dpkg -x xserver-xorg-dev_1.17.1-0ubuntu3_amd64.deb /
20:36 jennifeiro: dpkg -x xserver-xorg-core_1.17.1-0ubuntu3_amd64.deb /
20:37 jennifeiro: then recompile the drivers you use latest ones are advisable
20:43 jennifeiro: some additional work is needed to get the latencies on radeon, sucks but have to be done since, people do not appear to have much clue, doing wrong things
20:47 NanoSector: hey, I was wondering if nouveau can use the bbswitch kernel module to power on and off an Optimus GPU instead of vgaswitcharoo
20:47 karolherbst: NanoSector: and what would be the benefit?
20:47 NanoSector: I'm suspecting vgaswitcharoo doesn't fully turn off my card as my fans kick in way more often with vgaswitcharoo + nouveau than with bbswitch + bumblebee
20:49 karolherbst: does your battery report power usage?
20:49 NanoSector: powertop does
20:49 NanoSector: though to be fair I haven't checked that
20:49 karolherbst: you could check if there is a significant difference
20:49 karolherbst: sometimes the EC firmware is just crap
20:50 NanoSector:checks
20:50 karolherbst: the EC firmware on clevo laptops are crap beyond total crap though, just like mine
20:50 NanoSector: :(
20:50 karolherbst: yeah
20:50 NanoSector: I'm using an Acer Aspire V7 Touch
20:51 NanoSector: 7.81W using bumblebee when idle
20:51 NanoSector: 7.58 as lowest
20:54 NanoSector: removing bumblebee caused compositing to stop working, welp
20:55 NanoSector: 13W with nouveau + vgaswitcharoo
20:55 karolherbst: uhh
20:56 karolherbst: runpm=0 set?
20:56 karolherbst: it takes a while until the card gets turned off though
20:56 NanoSector: no
20:56 karolherbst: anything inside /sys/kernel/debug/dri/1/clients ?
20:56 NanoSector: last nouveau message is "suspending kernel object tree..."
20:56 karolherbst: I see
20:56 karolherbst: so the card should be turned off
20:56 karolherbst: but isn't obviously
20:57 NanoSector: that file exists, but seems to be just headers for a table
20:57 NanoSector: "command, pid, dev, master, a, uid, magic"
20:57 karolherbst: airlied: who works most on the vgaswitcherhoo stuff?
20:58 jennifeiro: karolherbst: mjg59 and airlied did some stuff there
20:58 karolherbst: NanoSector: open a bug report on the freedesktop bugzilla then
20:58 NanoSector: mkay
20:59 NanoSector: do i attach something, or just describe my problem?
20:59 NanoSector: besides my specs obviously
20:59 karolherbst: not really, I am sure somebody will ask for logs or so, but no clue
20:59 NanoSector: there's also no vgaswitcharoo entry in /sys
20:59 karolherbst: it's in debugfs
20:59 karolherbst: mhh
20:59 karolherbst: we could check that
20:59 karolherbst: /sys/kernel/debug/vgaswitcheroo/switch
20:59 NanoSector: oh taht does exist
21:00 NanoSector: nvm
21:00 karolherbst: is the nvidia gpu DynOff?
21:00 NanoSector: says DynOff for nvidia
21:00 NanoSector: yes
21:00 karolherbst: k
21:00 NanoSector: bug report it is?
21:01 karolherbst: yes
21:01 NanoSector: aight
21:02 NanoSector: oh i already had an account, derp
21:03 jennifeiro: i just went over the bbswitch.c source file, and i would not see a reason why would not it work under nouveau
21:03 jennifeiro: over/through
21:03 karolherbst: because it doesn't have an interface
21:04 karolherbst: second bbswitch itself is a hack and has other problems
21:04 karolherbst: third nouveau can't use out of tree module interfaces
21:04 jennifeiro: dev_name(&dis_dev->dev), is_card_disabled() ? "off" : "on");
21:05 NanoSector: what package do i file this for?
21:05 NanoSector: or what project
21:05 jennifeiro: device has to be changed only i think
21:05 karolherbst: jennifeiro: you don't get what I meant
21:05 jennifeiro: aah, wait digesting
21:07 karolherbst: Lekensteyn: any ideas?
21:07 karolherbst: Lekensteyn: we found a case where bbswitch turns the gpu off, but vgaswitcheroo fails
21:08 NanoSector: i feel like i'm only complaining here about stuff that doesn't work lol, sorry about that
21:08 karolherbst: it's normal
21:08 karolherbst: usually nobody complains about working stuff
21:08 NanoSector: i think you're doing an awesome job though
21:08 NanoSector: haha
21:08 karolherbst: "crap, why does reclocking work, damn nouveau"
21:08 jennifeiro: heh
21:09 NanoSector: i really wish i could send you guys my laptop or something because it seems to be an edge case in more than one area
21:09 karolherbst: allthough there are those special somebodies saying that the energy spent on nouveau is better spent somewhere else
21:09 karolherbst: ...
21:09 Lekensteyn: karolherbst: got more details? what laptop model is affected?
21:09 karolherbst: Lekensteyn: talk to NanoSector
21:09 NanoSector: Acer Aspire V7 Touch with a GT750M
21:10 Lekensteyn: hmm, so an older one. Is there a bugreport with dmesg and acpidump?
21:10 jennifeiro: karolherbst: his status is away, it seems , otherwise he would had allready said something probably
21:10 NanoSector: nope, sorry, I wanted to file one but have no idea where to file it
21:10 jennifeiro: huhuu
21:10 karolherbst: jennifeiro: I don't care about IRC status
21:10 NanoSector: jennifeiro: it's like you're speaking of the devil ;)
21:10 Lekensteyn: NanoSector: well, you know what to do now :)
21:10 NanoSector: Lekensteyn: heh :)
21:11 NanoSector: though I see like a hundred projects on freedesktop.org but nothing vgaswitcheroo or nouveau or kernel
21:11 Lekensteyn: I believe the category is DRI/nouveau
21:11 Lekensteyn: see https://nouveau.freedesktop.org/wiki/Bugs/
21:11 NanoSector: ohh subcategories, fun
21:12 NanoSector: thanks
21:13 jennifeiro: btw i get my gt730 back
21:18 NanoSector: so I'm extracting my vBIOS using nvagetbios and it complains about an invalid signature, both regular nvagetbios and nvagetbios -s prom, does that hurt?
21:23 NanoSector: https://bugs.freedesktop.org/show_bug.cgi?id=98398
21:37 Lekensteyn: NanoSector: vgaswitcheroo is probably the wrong keyword, but ok. Can you also upload your acpidump? (install the iasl package on for that)
21:37 Lekensteyn: s/on for that/on Arch Linux for that/
21:38 NanoSector: yep, on it
21:38 Lekensteyn: when have you first tried nouveau? does the same problem occur with kernel 4.7?
21:39 NanoSector: a wild acpidump.txt appears
21:39 NanoSector: (uploaded)
21:39 NanoSector: Lekensteyn: it has occured with all kernels I've tried up to this point, that includes 4.3 to 4.8
21:39 Lekensteyn: one difference between bbswitch and your situation is that nouveau now uses ACPI power resources while bbswitch uses the vendor-specific DSM method
21:39 NanoSector: mhm
21:40 NanoSector: is it possible that i need acpi_call for this??
21:40 NanoSector: *-?
21:40 Lekensteyn: the poewer resources method is superior though
21:40 Lekensteyn: no, you should not touch acpi_call, it is something that the driver should handle
21:40 NanoSector: okay
21:41 jennifeiro: NanoSector: for once i think you should grow up , vine lot less and start using your laptop connecting it into power outlet:D:D
21:42 Lekensteyn: NanoSector: can you also add the output of: lspci -tnnv
21:42 NanoSector: jennifeiro: I wish I could all the time ;) it's kind of a bummer if your laptop lasts 2x less on battery, especially if you need it at school and don't have a power outlet nearby all the time
21:42 NanoSector: Lekensteyn: sure, on it
21:43 NanoSector: done
21:44 jennifeiro: actually now that i remember one famous guy once said, that i am not a psychologist, but it seems like this guy could not handle that the stuff got done, it was said to cruel kloofy, he was about to throw up though
21:44 NanoSector: jennifeiro: i didn't understand anything you just said :P
21:45 jennifeiro: aaah it was actually kinda heads up to the complaining about working stuff though
21:45 NanoSector: hehe
21:45 NanoSector: well I'm really happy with how easy it is to start using optimus nowadays :) just setting an environment variable, couldn't be easier right
21:48 Lekensteyn: NanoSector: what is the output of: grep . /sys/bus/pci/devices/0000:0{0:1c.4,1:00.0}/power/{control,runtime_status}
21:48 Lekensteyn: it should say "auto", "suspended", "auto", "suspended"
21:49 jennifeiro: i have long time ago delt a little with acpi, but should rely on lenkensteyns knowledge about that, as at the moment i can not comment pretty much anything on it
21:49 NanoSector: like i said i really wish i could like send this out to you so you could investigate it in your own time and on your own pace
21:49 NanoSector: it says on, active, auto, suspended
21:49 jennifeiro: when we go little more serious, but to continue on this working stuff subject, at least once i got a laptop now, that seems to be very well supported under linux
21:50 NanoSector: though the first device is 0000:00:1c.4, the second is 0000:01:00.0 (which is my NVIDIA GPU)
21:50 Lekensteyn: problem possibly found
21:50 jennifeiro: those buttons and stuff i have one them work also via acpi
21:50 Lekensteyn: sudo sh -c 'echo auto > /sys/bus/pci/devices/0000:00:1c.4/power/control'
21:50 NanoSector: oh wait you explicitly grep'ed for 1c.4, derp
21:51 NanoSector: now it's auto, suspended, auto, suspended
21:51 Lekensteyn: with PR-style PM, the parent pcie port must also be configured for runtime pm
21:51 NanoSector: ahh
21:51 Lekensteyn: otherwise the power savings are not enabled
21:51 NanoSector: i see
21:51 Lekensteyn: you can create a udev rule for this
21:51 NanoSector: running powertop
21:52 NanoSector: still ~13, 14 W
21:52 NanoSector: 17W even
21:52 Lekensteyn: is the runtime status still suspended?
21:52 imirkin: NanoSector: were you the guy who just filed the bug?
21:52 NanoSector: imirkin: yes, are you here to tell me I suck at filing bugs? :P
21:52 imirkin: NanoSector: nope, just checking that not yet-another person has an identical issue
21:53 imirkin: Lekensteyn: didn't you change it to not use _DSM anymore?
21:53 NanoSector: Lekensteyn: no, it's on, active, auto, suspended again
21:53 imirkin: perhaps there's an issue around that? (haven't read the full log)
21:53 Lekensteyn: imirkin: yes since 4.8-rc1 it will not use DSM anymore if the PCI platform has support for _PR3
21:54 NanoSector: Lekensteyn: i just ran it again and now after powertop it stays on auto,suspended,auto,suspended but still 14W
21:54 NanoSector: compared to ~7W with bbswitch
21:54 Lekensteyn: NanoSector: you have filed the wrong bug category btw, the mails are not appearing to the nouveau list
21:54 imirkin: Lekensteyn: anyways, as long as you're on top of it, fine by me :)
21:54 NanoSector: I couldn't see DRI/Nouveau, so I filed to DRI/other
21:54 imirkin: NanoSector: xorg -> Driver/noueau
21:55 NanoSector: but xorg is for the DDX right?
21:55 imirkin: i've updated it
21:55 imirkin: in theory yes
21:55 imirkin: in practice we use it for both
21:55 NanoSector: thanks
21:56 NanoSector: told you i suck at filing bugs
21:56 NanoSector: :P
21:58 jennifeiro: Lekensteyn: care to tell where do you keep the code for this _PR3 methotic bbswitch?
21:58 Lekensteyn: jennifeiro: it is on one of the development branches of bbswitch in an incomplete form
21:59 Lekensteyn: to be able to use the new functionality in kernel 4.8, the easiest way is to properly write a pci driver, otherwise it will just not work
22:00 Lekensteyn: if you want to know what is done in nouveau for PR3 support, see git log drivers/drm/nouveau/nouveau_acpi.c
22:04 jennifeiro: Lekensteyn: lots of things to recap again, go around in different reading circuits, as ive settled down i arrive there again some day
22:04 jennifeiro: go/i go
22:05 NanoSector: it seems it stays on auto,suspended,auto,suspended unless i run powertop
22:05 jennifeiro: Lekensteyn: but what you mean by writing a pci driver, well nvidia driver is a pci driver?
22:05 Lekensteyn: jennifeiro: or see the patches on the list: https://lists.freedesktop.org/archives/nouveau/2016-July/025607.html
22:05 Lekensteyn: NanoSector: btw, I hope you have not combined bbswitch and nouveau in one boot?
22:06 NanoSector: nope
22:06 NanoSector: i removed everything bumblebee and nvidia
22:06 jennifeiro: Lekensteyn: ok, you mean ones should enhance the gpu driver a bit including the nvidia binary
22:07 NanoSector: [ 2017.278371] intel_pstate: Turbo disabled by BIOS or unavailable on processor
22:07 jennifeiro: nvidia binaries kernel module that is
22:07 NanoSector: I've not seen that before though
22:08 Lekensteyn: JackWinter: no, I was referring to bbswitch. It is currently a hack and breaks when you do unusual things (like removing/re-probing the PCI device while bbswitch is still loaded)
22:08 Lekensteyn: to make bbswitch better, it should be using the pci driver model
22:09 jennifeiro: ouh crap my bad, it was me and NanoSector who both commented that we want bbswitch to work under nouveau:)
22:10 NanoSector: i don't really want bbswitch to work under nouveau, if vgaswitcharoo shuts off my card I'm happy with it as well :P
22:10 NanoSector: dafuq
22:10 NanoSector: okay
22:10 Lekensteyn: jennifeiro: see https://github.com/Bumblebee-Project/bbswitch/commits/pm-rework for changes that are inccomplete
22:11 jennifeiro: yeah, cause with nvidia there is nothing really to do , cause it allready works properly with current methods
22:11 NanoSector: so if I run powertop on battery, the status becomes on,active,auto,suspended, that error message about CPU boost appears in dmesg, and my bluetooth gets disconnected (as USB device...?)
22:11 NanoSector: then a while later bluetooth 'reappears'
22:12 NanoSector: or rather a usb device appears, using xhci_hcd
22:12 NanoSector:is confused
22:12 Lekensteyn: NanoSector: do you have a dmesg after auto,suspended,auto,suspended?
22:13 NanoSector: i'll attach a new dmesg log
22:14 Lekensteyn: maybe you can also upload (in addition to the existing lspci -tnnv log) the output of: sudo lspci -nnvvv
22:18 NanoSector: added new dmesg to bug report
22:18 NanoSector: also added Lekensteyn
22:19 jennifeiro: jennifeiro: people allready probably know who am i anyways, i came to my summerplace having a bit rest, and configured my amd laptop, i will be working on bit other tasks
22:19 jennifeiro: talking to myself now
22:19 NanoSector: reminds me, my friend has a laptop with dedicated amd gpu, still have to figure out with him how to use that
22:20 jennifeiro: i was about to order one myself too, it was samsung model, but got an apu instead later
22:20 NanoSector: :)
22:21 NanoSector: yeah his has like an AMD E3 processor with integrated graphics and a Radeon 6400M dedicated
22:21 NanoSector: the power of the 6400M could come in real handy for him :P
22:23 jennifeiro: well yeah i wanted every vendors cards to try working on Lekensteyn i laid my eyes on those patches a bit, but generally everything that about graphics muxing and pm, isnt something i care about
22:25 jennifeiro: Lekensteyn: but do you think that gentelman here having trouble could use such functionality in those proposed patches to spare his battery somehow using nouveau?
22:25 jennifeiro: is the state of the code enough mature to do that?
22:25 NanoSector: fun, linux 4.8.4 landed
22:26 Lekensteyn: jennifeiro: I could not parse the last part of your sentence, the patches were merged in in 4.8-rc1 and saves battery and prevents memory corruption (on some Lenovo models)
22:26 Lekensteyn: what is your question?
22:27 Lekensteyn: NanoSector: with a fix for Dirty COW as well :)
22:27 NanoSector: woo
22:27 jennifeiro: Lekensteyn: my question is that if NanoSector could make use of those patches?
22:27 NanoSector: should update my homeserver too
22:28 NanoSector: brb
22:28 Lekensteyn: jennifeiro: well, since he is already using kernel 4.8.3 he is already using them!
22:28 jennifeiro: aaah ok...
22:30 NanoSector: 4.8.4 now :)
22:32 NanoSector: [ 7.196351] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
22:32 NanoSector: what's that?
22:32 NanoSector: :o
22:33 jennifeiro: cluster of machines you have then, ouh dear
22:33 jennifeiro: :D:D
22:33 NanoSector: hmm?
22:33 jennifeiro: some sort of big number of GART memory
22:33 jennifeiro: was my joke that it took it from all machines and added up
22:34 NanoSector: ah
22:34 NanoSector: i don't have any other machines with nvidia gpus :P
22:34 imirkin: NanoSector: 1TB maximal gart, due to a 40-bit VM address width.
22:34 NanoSector: mhm makes sense (i've no idea what that is :P)
22:34 imirkin: 40-bit = 1TB
22:35 imirkin: can't address more than 1 TB of system memory otherwise.
22:36 Lekensteyn: NanoSector: after enabling runtime PM for the port, do you see an improvement now?
22:36 NanoSector: oh nice, 2^40/1024^4 = 1
22:37 NanoSector: Lekensteyn: no
22:37 NanoSector: :P
22:37 NanoSector: well at least not in powertop, not sure if there's other methods of measuring power usage
22:37 NanoSector: i think something in powertop is triggering it to turn on again
22:38 NanoSector: wat
22:38 NanoSector: now if I run powertop, it shows me ~14W power usage
22:38 NanoSector: and if I check that grep .. /sys/bus/pci thingy, it says auto,suspended,auto,suspended
22:39 NanoSector: after powertop
22:39 imirkin: it's almost as if 2^10 = 1024...
22:39 NanoSector: imirkin: fascinating
22:40 NanoSector: no wait it reverted to on,active,auto,suspended again
22:43 Lekensteyn: NanoSector: I have some udev rules to enable PM at boot, too busy to clean it up properly, but maybe you can some hints here http://sprunge.us/dVRU
22:43 NanoSector: my fans stay on as well even when it's auto,suspended,auto,suspended, so it's not turning off
22:43 NanoSector: thanks, will take a look
22:45 NanoSector: I think TLP can do a similar thing
22:45 NanoSector: i do run TLP
22:45 NanoSector: although i told it not to touch pci stuff
22:48 jennifeiro: NanoSector: maybe this TLP is the one that screws the mission:) somehow
22:48 NanoSector: i'll reboot and check without it
22:50 Lekensteyn: NanoSector: can also try to tune tlp to touch pci stuff
22:50 Lekensteyn: baking a 4.8.4 kernel, it is getting hot here :p
22:52 NanoSector: no dice, as many watts without TLP as with it
22:53 Lekensteyn: is the state auto,supended,auto,suspended?
22:53 NanoSector: on bootup, yes
22:55 NanoSector: ok something is turning the GPU on if i plug in power
22:55 NanoSector: it's not TLP
22:56 NanoSector: tell you what i'll remove TLP and reboot to make sure it's not there anymore
22:57 Lekensteyn: but is it turning off automatically after that? (default runtime suspend delay is 5 seconds)
22:57 NanoSector: the card is, the bus is not
22:58 NanoSector: ok, no tlp, fresh boot, on battery
22:58 NanoSector: auto, suspended, auto, suspended
22:58 jennifeiro: well do i understand correctly that you want to switch off the NVIDIA gpu when you do not need it right or make it go idle and back on on demand
22:58 NanoSector: plug in power adapter, and it now stays auto suspended auto suspended
22:58 NanoSector: wtf
22:59 jennifeiro: but watts?
22:59 NanoSector: still 14W
23:00 NanoSector: and after powertop it's still a,s,a,s
23:00 jennifeiro: damn it, well try those udev rules then too, or actually maybe there is no point even
23:00 NanoSector: i'll try those
23:03 NanoSector: with those rules
23:03 NanoSector: 16W
23:03 NanoSector: no, 13
23:04 jennifeiro: i just did not want to go to sleep, its quite logical that with missions i intend to do, i still need to control the power on some system events
23:04 NanoSector: uh
23:04 jennifeiro: NanoSector: did you use that script verbatim?
23:04 Lekensteyn: to try pre-4.8 behavior (DSM instead of PR3) you can also try to boot with "pcie_port_pm=off" added to your cmdline, but it should not be worse
23:04 NanoSector: i don't understand what you're trying to say
23:04 NanoSector: jennifeiro: verbatim?
23:05 NanoSector: Lekensteyn: I'll try, thanks
23:05 NanoSector: Lekensteyn: is that nouveau.pcie_port_pm=off or just pcie_port_pm=off?
23:06 Lekensteyn: the latter, it is part of the pci core
23:06 jennifeiro: NanoSector: cause it did not modify the states of the cards right, verbatim=unchanged
23:06 NanoSector: Lekensteyn: added, thanks
23:06 NanoSector: jennifeiro: i still don't understand, but rebooting so bbiab
23:08 jennifeiro: i dont probably have those devices, but i figured probably there are states for the bus and card, why the heck would be there four sttes otherwise right
23:08 jennifeiro: states
23:09 NanoSector: now i get auto,active,auto,suspended
23:09 NanoSector: and indeed 7.84 W O_o
23:09 jennifeiro: yessssss
23:09 NanoSector: wat
23:10 NanoSector: so even if the parent bus is active it can be off?
23:12 jennifeiro: hardly matters as far as it works
23:12 jennifeiro: :)
23:12 NanoSector: and my fan stopped
23:13 NanoSector: Lekensteyn: i think that was it
23:14 jennifeiro: fasimating session you did, i head off to sleep now, was quite interesting, well nouveau starts to go to heights probably at one stage anyways
23:14 Lekensteyn: jennifeiro: if you check the command, there is one for the runtime pm state (auto[magic] or [always] on), double that for the parent pci port
23:14 Lekensteyn: NanoSector: what have you changed?
23:15 NanoSector: Lekensteyn: i added pcie_port_pm=off to the kernel command line
23:16 Lekensteyn: that is strange
23:16 jennifeiro: exactly i understood also, that something is reversed
23:16 Lekensteyn: can you give another try without the boot option, but with nouveau initially blacklisted at boot
23:16 NanoSector: sure
23:16 jennifeiro: but hardly matters, you could now take it from there, since the behavior is right
23:16 Lekensteyn: wait, there are more instructions
23:17 NanoSector:listens
23:17 Lekensteyn: once you boot up, echo 0 > /sys/bus/pci/devices/0000:01:00.0/d3cold_allowed && modprobe nouveau
23:18 Lekensteyn: that should have the same effect as that kernel parameter, but is then limited to the nvidia card
23:18 NanoSector: aight
23:18 NanoSector: brb
23:20 NanoSector: Lekensteyn: yes, that causes powertop to report the same value
23:20 NanoSector: of ~7.5W
23:20 NanoSector: and hopefully my fan to turn off in a while
23:20 NanoSector:hates the humming sound
23:21 Lekensteyn: hmm, this is new information for me (PR3 not fully working while DSM does)
23:21 Lekensteyn: can you add the details to the bug, then I can have a look at it later (in >= 2 weeks, got some exams coming up ;))
23:22 NanoSector: sure :) thanks for checking it out, take your time
23:22 NanoSector: i'll just add pcie_port_pm=off to my kernel command line for now
23:24 NanoSector: and good luck with your exams :)
23:24 NanoSector: what subjects?
23:26 Lekensteyn: one in "phsyical aspects of digital security" (incl. quantum crypto), some project work (information retrieval and data mining), there is plenty to do ;)
23:27 NanoSector: you're studying security?
23:29 NanoSector: i remember going to some university to take example lessons, i took a lesson on cryptography
23:29 NanoSector: couldn't even solve the caesar code :)
23:29 NanoSector: i'll stick to developing IRC bots instead, on a nice high level :P
23:29 NanoSector: *high level language
23:30 jennifeiro: ouh geniuses here, i saw a movie about quantum technology though, as i have educated myself a little, the circuit could be interesting in electronics
23:31 jennifeiro: it had three states in theory not two anymore like 1 and 2
23:31 jennifeiro: err 1 and 0
23:31 jennifeiro: it had 1 and 0.5 and 0 states
23:32 imirkin: jennifeiro: stay on topic.
23:32 NanoSector: sorry, i derailed the topic :P
23:33 jennifeiro: topic ends for today by me, i dont know at all about current nouveau code, i stayd awake cause i suddenly understood
23:34 jennifeiro: that this information they talked about, i really need that info
23:38 jennifeiro: but i have further questions i am afraid..
23:39 jennifeiro: so the iasl or something is cpu acpi tables probably an interrupt based, how does the gpu hw really communicate to the cpu, probably via hw interrupt?
23:41 jennifeiro: actually this does not matter in my specific case much, i could send whatever i want when acpi signal is received
23:42 NanoSector: i don't think anyone thinks that you make sense right now, sorry :P
23:42 NanoSector: and my bloody fans started running again :(
23:46 jennifeiro: i dont think they know what sense is btw...
23:49 jennifeiro: i dont wanna comment in here anymore, in fact that was last thing i needed, it works so that via acpi processor gets a signal that one of cards is needed to be switched off, then its delivered to the controller or card , message is got back probably via hw interrupt, and then bus is made idle too