07:11 pq: imirkin_, yes, I think valgrind "should" be taught or told about those ioctls. It won't magically know which bits the kernel actually reads or writes. I suspect there are two ways to do that: Valgrind annotations around the ioctl call, and describing the ioctl itself in Valgrind sources.
07:12 pq: imirkin_, e.g. apps using intel drivers are near impossible to debug with valgrind unless you build libdrm with valgrind support.
07:13 pq: it's a flood of false positives otherwise
09:02 xexaxo: pq, imirkin: some of those annoyances have been fixed (silenced/papered over/etc.) by explicitly zeroing the struct before being fed to the kernel
09:03 xexaxo: it saves you the explicit annotations and rebuilding libdrm with Valgrind.
09:03 xexaxo: admittedly not perfect of a 'fix', but the easiest/quickest one.
09:06 pq: it's sometimes also a required fix, to not pass garbage into the kernel, if the kernel is reading any bits of it.
09:46 KSteffensen: hi
09:46 KSteffensen: does anybody know if there is a solution to this bug https://bugs.freedesktop.org/show_bug.cgi?id=94990 ?
09:47 KSteffensen: new 4.6 kernel won't boot with nouveau and a gtx970 card....
10:00 karolherbst: KSteffensen: gnurou wrote that code, I think he had some fixes somewhere, but no idea in which state they currently are
10:02 gnurou: KSteffensen: yeah, there is a fix to at least allow you to get a display, however the firmware would still not be loaded and I don't know why some users are hitting this issue...
10:14 KSteffensen: ok
10:14 KSteffensen: anything I can do to help out?
10:17 gnurou: KSteffensen: I need to re-check that bug and see if I can find some hints from the logs, for now I am rather clueless sadly
10:18 gnurou: KSteffensen: btw, the fix that will allow you to get display at least: http://comments.gmane.org/gmane.comp.freedesktop.xorg.nouveau/25142
10:41 RSpliet: Ben on a little holiday?
10:45 tacchinotacchi: hey you guys are surely more experienced on assembly
10:46 tacchinotacchi: if I open nvidia-settings and put the mouse on the Graphics clock, a popup appears saying "This indicates the current Graphics Clock frequency."
10:47 tacchinotacchi: opening the executable with hexedit, I can't find that string
10:47 karolherbst: tacchinotacchi: nvidia-settings is open source
10:48 tacchinotacchi: aw
10:48 karolherbst: https://github.com/NVIDIA/nvidia-settings
10:48 tacchinotacchi: I was about to say the executable had been deliberately obfuscated haha
10:48 tacchinotacchi: thank you
10:49 karolherbst: anyway, I don't think it will help in an way anyway :p
10:49 tacchinotacchi: likely
10:50 tacchinotacchi: karolherbst: that was more of an exercise in assembly reverse engineering than nvidia driver
10:50 karolherbst: ahh
10:51 tacchinotacchi: still I'm wondering how they made that string lol
11:06 Calinou: lol, nvidia-settings is on GitHub, TIL
11:10 poly_: hi
11:10 poly_: I'm not sure if this is the right place to ask... but is there a way to downclock the GPU card through nouveau?
11:10 RSpliet: poly_: depends a lot on your GPU
11:11 poly_: my issue is that it keeps hitting very high temperature (could be also because the laptop is bit older), so maybe lowering the performance could help
11:12 RSpliet: poly_: which GPU are we talking about?
11:12 poly_: I have ThinkPad T520 with NVIDIA Corporation GF119M [Quadro NVS 4200M] (I'm using bumblebee/optirun to switch)
11:12 RSpliet: ah, oh
11:12 RSpliet: no, that's most likely already running at it's lowest performance level
11:12 RSpliet: but do double-check with cat /sys/kernel/debug/dri/<number>/pstate
11:12 RSpliet: if that file doesn't exist, either you need to mount debugfs or if it's mounted, your kernel is out of date
11:13 RSpliet: this requires root access
11:14 poly_: pstate is not there; my kernel is 4.5.0-2-amd64 #1 SMP Debian 4.5.5-1 (2016-05-29) x86_64 GNU/Linux
11:14 poly_: so maybe it's not mounted
11:15 RSpliet: mount -t debugfs debugfs /sys/kernel/debug
11:15 poly_: well... /sys/kernel/debug/dri/{0,128,64}/ is there, just not the pstate in any of the folders
11:15 RSpliet: is there a vbios.rom in any of those folders?
11:16 poly_: no
11:16 RSpliet: could you paste your full dmesg onto a paste website of choice please?
11:18 poly_: http://pastebin.com/PUWrjF83
11:21 RSpliet: there's no mention of nouveau in there...
11:23 RSpliet: (bumblebee is no longer recommended in combination with nouveau btw, it's been superseded with cleaner support called 'prime')
11:25 poly_: this is what I got after I executed optirun
11:25 poly_: http://pastebin.com/ENcUBrKc
11:25 poly_: (in dmesg)
11:25 poly_: is prime primusrun, or something else?
11:26 RSpliet: no, prime is integrated with the whole drm stack
11:26 RSpliet: but to come back to your original question, you're not using nouveau
11:26 RSpliet: but the proprietary nvidia driver
11:27 RSpliet: which should take care of your clocks properly (but they are unlikely to support bumblebee set-ups if you need support)
11:27 poly_: welp I'm an idiot... I've copy-pasted the wrong line from debian wiki when I was installing it
11:28 poly_: sorry to take your time... time to reinstall to nouveau
11:28 poly_: but the proprietary driver also clearly has trouble with thermal
11:28 RSpliet: it might just be a laptop full of dust?
11:28 karolherbst: poly_: anyway, your heat problems aren't related to your GPU
11:29 karolherbst: RSpliet: no, it's lenovo :p seriously speaking, I heard a lot of thermal problems with low end lenovo laptops
11:29 karolherbst: *about
11:29 poly_: it was cleaned recently, so maybe it's just older (~5 years of use)
11:29 RSpliet: either way, try and use the prime set-up rather than bumblebee. For me (Fedora 24) it worked out of the box, no extra software required
11:29 RSpliet: and I'm guessing that's no different on Debian if you have a 4.5 kernel
11:30 karolherbst: poly_: but you have to expect the GPU to get hot when you start using it and hot is lime 90°C +
11:30 karolherbst: *like
11:30 poly_: that's what I am getting... 90C, which is worrying considering the core has high at 86 and critical at 98
11:31 karolherbst: for CPUs that is even more normal
11:31 karolherbst: on load your CPU will hit 98 °C
11:31 karolherbst: it's just the way it is
11:31 karolherbst: you can disable turbo boost though
11:31 poly_: really? normally CPU sits around 40-60
11:31 RSpliet: karolherbst: no it isn't... laptops are designed to sit on laps. Laps are not designed for near-boiling temperatures
11:31 poly_: so I shouldn't be too worried about the laptop being hot like an oven?
11:31 karolherbst: RSpliet: they do
11:32 karolherbst: poly_: only on load
11:32 RSpliet: poly_: check powertop as well, there might be reasons why your CPU doesn't clock down properly when idle
11:32 karolherbst: poly_: if there is no CPU load, the cpu should go down below 50°
11:32 poly_: yeah but if it's for prolonged period of time... hours?
11:32 karolherbst: check powertop
11:32 karolherbst: and top
11:32 karolherbst: there might be a process going crazy
11:33 karolherbst: "Idle stats" in powertop
11:33 RSpliet: Tunables as well. Quirks like a CPU not clocking down when power save for SATA isn't enabled spring to mind
11:33 karolherbst: RSpliet: with recent intel cpus the clock doesn't matter much
11:33 karolherbst: idle states is the only important thing
11:34 RSpliet: it's a laptop with Fermi
11:34 karolherbst: and
11:34 karolherbst: ?
11:34 karolherbst: I also had a laptop with fermi
11:34 RSpliet: that makes the CPU 6 years old
11:34 RSpliet: not recent
11:34 karolherbst: it was a sandy bridge
11:34 karolherbst: well
11:34 karolherbst: sandy bridge also follows the same rule
11:34 karolherbst: ilde states are important, clocks not so much
11:34 karolherbst: mhh
11:35 karolherbst: actually my laptop was a ivy bridge
11:35 poly_: so if the GPU is on 90C for two hours that's nothing to be worried about?
11:35 poly_: (because it's being used)
11:35 RSpliet: karolherbst: https://mjg59.dreamwidth.org/41713.html?thread=1635569
11:36 RSpliet: poly_: no I'd worry about that in a laptop
11:36 karolherbst: RSpliet: well that's skylake
11:36 karolherbst: poly_: well the gpu should be off when not in use
11:36 RSpliet: karolherbst: *sigh* the point I'm trying to make is that tunables could have a bigger impact than you'd expect due to hardware quirks
11:37 poly_: but if you have something using it... e.g. a game then the gpu will be always in use, no?
11:37 karolherbst: right, but that's about package states usually
11:37 karolherbst: and those don't matter as much as the core idle states
11:37 karolherbst: poly_: it will, yes
11:37 RSpliet: "On Haswell/Broadwell this manifested in the form of Serial ATA link power management being involved in preventing the package from going into deep power saving states - setting that up correctly resulted in a reduction in full-system power consumption of about 40%[1]."
11:37 RSpliet: it matters
11:38 karolherbst: RSpliet: yeah, on idle
11:38 RSpliet: no clearly not on full load
11:38 karolherbst: well, for me pc2 -> pc3 is like 1W
11:39 karolherbst: and this is about idle
11:39 karolherbst: because the cpu package only enters deeper idle states when nothing is using it
11:40 RSpliet: poly_: under load it's expected. 90 degrees is a lot but poor thermal design in laptops could cause such temps
11:40 RSpliet: but as I said, if it's housing a family of dustbunnies it's cooling capacity decreases
11:41 karolherbst: new thermal paste also helps
11:41 RSpliet: if you *can*, try checking how bad the internals are and give it a good blow w/ compressed air
11:41 RSpliet: or a vacuum cleaner
11:42 RSpliet: (in which case it's a suck, but you catch my drift)
11:42 poly_: I had it opened couple of weeks ago and was cleaning it a bit, but it already looked quite clean
11:43 karolherbst: poly_: can you open the fan covers?
11:43 karolherbst: sometimes behind the cooling stuff there is dust
11:43 poly_: I didn't open that, hmm
11:43 poly_: ok, so todolist: 1) look at fan covers 2) install prime 3) see how it behaves :)
11:43 poly_: thank you all!
12:29 tacchinotacchi: any news on fermi reclocking?
12:29 tacchinotacchi: yes I know I'm too lazy/stupid to do myself
12:38 RSpliet: tacchinotacchi: stalled, I have no time to continue currently
12:38 RSpliet: maybe next month I can pick it up again
12:39 RSpliet: I thought I was close to bringing one specific GDDR5 card to the middle perflvl, but it doesn't work yet, and that last 5% could well be 90% of the work
12:39 RSpliet: (so, there's nothing to test, nothing serious that will be merged any time soon)
12:51 tacchinotacchi: if they hadn't told me it takes 6 months to get used to the code..
12:52 tacchinotacchi: which part contains reclocking? the kernel or libdrm?
12:56 mwk: tacchinotacchi: kernel
13:00 tacchinotacchi: thx
13:01 RSpliet: tacchinotacchi: for what it's worth, here's the WIP -> https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master
13:01 RSpliet: but unless you're serious about development, it'd be of little use. There's no point in just testing it at this point
13:02 tacchinotacchi: RSpliet: dunno, driver is a new field to me
13:02 tacchinotacchi: and i don't know anything about nvidia gpu's internals
13:06 tacchinotacchi: jeeze, is github downloading at 70 kb/s for me only?
15:02 karolherbst: maybe I should have put a BUG_ON in the default case, because it can't be reached anyway...