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