00:05pmoreau: imirkin_: Sure, will do that right now
00:10pmoreau: Hum... How do I run it btw? Do I add it as a test to Piglit?
00:10imirkin_: bin/shader_runner in piglit
00:10imirkin_: feed it in as the argument
00:10imirkin_: (and then -fbo -auto)
00:10pmoreau: Ok, thanks
00:11pmoreau: Just need to recompile Piglit and I should be good
00:12imirkin_: if you already have an old one built, no need to rebuild
00:12imirkin_: shader_runner doesn't change much
00:12imirkin_: and that test file doesn't use any of the newer features
00:12pmoreau: I removed Piglit from my machine some time ago cause I was **really** low on disk space
00:20pmoreau: Removing "+ arg2" from line 19 on MCP79 fails with "cannot get location of uniform "arg2""
00:20imirkin_: can you nuke the uniform setting it too?
00:20imirkin_: (just one place)
00:21pmoreau: Pass now :)
00:21pmoreau: Now, let's head to the G96
00:21imirkin_: and you're using a mesa that has the relevant commit right?
00:21imirkin_: i.e. the one you bisected to
00:22pmoreau: I am right on the relevant commit
00:23pmoreau: And you were right
00:23pmoreau: With +arg2, works, without, fails
00:23imirkin_: but it worked on the nvac right?
00:24imirkin_: ok cool. i'm just going to make it conditional on >= 0xa0
00:24pmoreau: Great :)
00:25Weaselweb: hi guys. i have a nvaa which has problems on shutdown when CONFIG_PM (and thus runtime pm is enabled). starting from device_shutdown() to __pm_runtime_barrier for struct device from nouveau, the kernel waits forever at least too long) to be woken up at dev->power.wait_queue
00:26Weaselweb: kernel is 3.19
00:28pmoreau: I'm off.
00:28pmoreau: imirkin_: I'll do some additional testing this evening if you need
00:29imirkin_: pmoreau: ok cool. i'm about to send a patch, give it a shot later on
00:29pmoreau: Sure, will do
00:29pmoreau: Thanks for having a look at it! :)
00:31pmoreau: Weaselweb: Could you paste your dmesg please? (Hopefully someone can have a look at it, I gtg)
00:32imirkin_: pmoreau: patch sent
00:32Weaselweb: here is dmesg from a failed shutdown: http://pastebin.com/DWkyvmsB
00:32pmoreau: imirkin_: Hum... Ok, I'll try it right now :D
00:33Weaselweb: this is dmesg from shutdown success: http://pastebin.com/A158Nzbq
00:37imirkin_: pmoreau: also available at https://github.com/imirkin/mesa/commit/967279c23aeb4af035e4b309e3ec9afcd029e4a1.patch
00:37Weaselweb: I know from my added printk that dev->power.runtime_status is RPM_SUSPENDING when calling schedule() inside __pm_runtime_barrier
00:37imirkin_: let me know how it goes... /me &
00:39pmoreau: imirkin_: Working! Thanks a lot! :)
00:39pmoreau: Weaselweb: Do you have full dmesg?
00:43Weaselweb: pmoreau: see here: http://pastebin.com/czwCH4B9
00:43Weaselweb: note that I've added some printk to see what's going on. unfortunately those dev_info are printed for every device :(
00:46pmoreau: Is this something new to 3.19?
00:46Weaselweb: oh, this is taken from serial console
00:46Weaselweb: pmoreau: I guess this was also happening with older kernels, from the point where runtime pm was added to nouveau
00:47Weaselweb: If I set CONFIG_PM=n everything is fone (at least 4 out of 4 shutdowns suceeded, normaly it is about < 40% only)
00:47Weaselweb: *is fine
00:48pmoreau: And if you set nouveau.runpm to 0?
00:49pmoreau: Sorry, gtg for real now
00:49Weaselweb: never tried, but I expect this would be ok.
00:50Weaselweb: I'll try that module parameter
01:57Weaselweb: pmoreau: while I was bisecting another bug (will write about it in a second), I was using runpm=0 and my systemd a clean poweroff in 8 out of 8 tries! so this is definitely a workaround. I'm still wondering a bit about this. this means that in nouveau_drm_load calls to pm_runtime_use_autosuspend and so on (dependend on nouveau_runtime_pm != 0) still has some effect, even for non-optimus systems
01:59Weaselweb: the other issue is that X doesn't show any output starting from commit 0ea5fe8a83c2d1d59bcf1a59ba685a6452c41205, while fbcon is fine
02:01Weaselweb: I guess one of the DCB_CONNECTOR_HDMI_* is missing in the case for setting nv_connector->scaling_mode = DRM_MODE_SCALE_FULLSCREEN
02:16Weaselweb: ok, so my connector is DCB_CONNECTOR_HDMI_1 (0x61) which sets the scaling_mode to DRM_MODE_SCALE_NONE now. this apparently does not work on my hardware :(
08:10mupuf: imirkin_: isn't it a good idea to jump to a sched instruction?
08:13tobijk: imirkin: push that sat-disable patch already :D
09:28imirkin: mupuf: afaik there's no such thing as a sched instruction... just something we invented for envydis/envyas
09:28mupuf: what is it then? Did you see the reverse engineering done by someone outside of nouveau on what it was?
09:28imirkin: mupuf: i don't think i've ever seen the blob do it
09:29mupuf: that's indeed fair-enough
09:29imirkin: it's scheduling info for that block
09:29imirkin: blocks of 7 (+ sched) = 64 bytes on kepler (and kepler2)
09:29imirkin: blocks of 3 + sched = 32 bytes on maxwell
09:29imirkin: i did see the work someone else did on working out the meanings of the sched info on maxwell
09:30imirkin: in fact i even mentioned it in here
09:35mupuf: imirkin: that means that the processor will look back to find a scheduling block if you jump after one?
09:35mupuf: or just ignore it and pick the worse case scenario
09:35mupuf: I would say it is the latter
09:36mupuf: as there would be no point looking at it unless it is the instruction right before
09:36imirkin: mupuf: i assume the instruction decoding works in blocks
09:36imirkin: it's not like you jump and it starts decoding from that place in memory...
09:37mupuf: possible, indeed
09:37imirkin: there is no "worse case scenario"... the sched bits contain real information
09:37imirkin: it's not just like a delay
09:37mupuf: did you see any alignment with the sched info?
09:38mupuf: as in, they would always be at an address modulo a small number
09:38imirkin: yeah, like i said... groups of 64 bytes on kepler and groups of 32 on maxwell
09:38mupuf: that makes sense
09:39imirkin: i never did the RE on kepler2... i hope it's the same as on kepler1. since calim wrote that initial emitter, i assume he looked at it :)
09:56mupuf: imirkin: what would you guess a "iccsense" table would be?
09:59imirkin: mupuf: kepler2 = gk110/gk208
09:59mupuf: ok :)
09:59imirkin: iccsense? well, icc has to do with those stupid colors
09:59mupuf:has been away for sooo long...
10:00imirkin: could be I as in current, so sensing supply current
10:00mupuf: I should rename this table then :D
10:00imirkin: need a bit more context ;)
10:00mupuf: the second guess is right
10:00mupuf:is trying to name a vbios table
10:00imirkin: iccsense is fine
10:00mupuf: I should have said vbios table instead of table
10:01imirkin: probably :)
10:01mupuf: it contains the resistance values for the different power rails
10:02mupuf: and the association between the power rails and the external device
10:02mupuf: (when there is an external device per rail, the most common case)
10:16mlankhorst: what's the first letter?
10:44imirkin: tobijk: pushed
12:37tobijk: imirkin: fine :)
15:09tobijk: yay heisebugs are nice :/
16:28buhman: it makes me so happy when people update bug #70354
16:32imirkin: buhman: i bet there's one update that you'd like more than the others
16:32imirkin: "RESOLVED FIXED" :p
16:33tobijk_: you know something we don't? :D
16:33imirkin: probably several things
16:33imirkin: but not relating to this, unfortunately
16:36buhman: I've always wondered if nvidia employees look at the nouveau BTS for lulz
16:37buhman: (with no intention of providing input, just literally to laugh at issues)
16:38imirkin: i doubt it
19:55tobijk_: airlied: you broke my system with libdrm 2.4.61 :P
20:11airlied: tobijk_: broke how?
20:11airlied: and I think you'll find I just released it
20:11airlied: I doubt I had a patch anywhere near it
20:12tobijk_: yeah i just meant with releasing it
20:12tobijk_: it breaks the intel ddx driver somehow
20:13tobijk_: i'M going to bisect tomorrow, fyi :)