02:12trippeh_: ok, mmiotracing is aaalmost working.
02:13trippeh_: tracing is working that is, just have to figure out why Xorg is not enumerating the display.
02:14trippeh_: altough the tv is claiming 4K@60hz while on the console now, so maybe it got the needed bits ;)
02:21trippeh_: oh the kernel driver is complaining.
02:58trippeh_: nvidia kernel module fails to init adapter when mmiotrace is active.
03:11trippeh_: [ 202.004969] NVRM: RmInitAdapter failed! (0x26:0x40:1096)
03:11trippeh_: [ 202.005005] NVRM: rm_init_adapter failed for device bearing minor number 0
03:12trippeh_: tried to boot with only one cpu online in case the mmiotrace offlining them interfered somehow, no dice
03:56skeggsb: trippeh_: when running nouveau, copy /sys/kernel/debug/dri/0/vbios.rom somewhere, and before using the nvidia binary driver, use "nvafakebios /path/to/vbios.rom"
03:57skeggsb: that's solved the issue on a couple of systems i've tried to trace
03:57skeggsb: nfi why it happens though
03:57skeggsb: nvafakebios comes from envytools btw
04:03trippeh_: run nvafakebios before or after loading the nvidia kernel modules?
15:06mwk: and that concludes NV4 non-drawing method tests
15:07imirkin: ah, so just the easy stuff left :p
15:07mwk: yeah, things are going to get interesting
15:09mwk: I suppose I could fail the pre-draw tests on purpose and test at least some parts of drawing methods without actually having to handle the surface logic...
15:31mooch2: mwk: i'd rather you didn't, as i'm relying on your tests for info
16:34Vollstrecker: Hi, anyone here that thought about bug #82527? I wanted to give a comment on that, but I don't want to create another account I won't ever use again.
16:37imirkin_: sounds like a bunch of separate issues in one
16:37imirkin_: are you experiencing such issues, and if so, with which gpu?
16:38Vollstrecker: I'm hitting the same bug now with my new Asus displays. The old ones were connected one via direkt dvi, and one via a dvi->vga adaptor over an kvm-switch. Both worked as expected with dpms turning them off. The new ones: one with the same adaptor and kvm still work, the other on a dvi->hdmi adaptor doesn't.
16:39imirkin_: which gpu?
16:40Vollstrecker: Sorry, had to search again: NVIDIA NVD9
16:41imirkin_: ok. that's a vastly different GPU than the one the bug was filed against
16:41imirkin_: either way, i'd recommend trying drm-next -- this changes a lot of the display code around to enable so-called "atomic modesetting"
16:41imirkin_: perhaps it also fixes your issue
16:42imirkin_: this should be in the upcoming 4.10-rc1 as well
16:44Vollstrecker: I can try, will it compile with 4.8.0 from debian testing?
16:45imirkin_: it's a full kernel tree
16:45imirkin_: based on 4.9 or so
16:46Vollstrecker: ok. I'll try on wednesday when my wife works all the day. If I start more experiments now, she'll kill me.
17:00Vollstrecker: k, crossreading the git-repo, I can't find anything named drm-next. Is it a replacement or did I search the wrong places?
17:00Vollstrecker: I didn't find any docs either.
17:05Vollstrecker: I found that already, I took a look into drivers/gpu and /drivers/gpu/drm but didn't read anything about drm-next. The question was: Is it still drm with new code, or something different I have to enable somewhere I didn't find it.
17:06Vollstrecker: Would be a bit stupid if I compile a new kernel for testing and didn't activated what I tried to test.
17:08imirkin_: it's a full kernel.
17:08imirkin_: it's a full kernel with new drm code.
17:08imirkin_: nothing special
17:14Vollstrecker: Sure, got that. But drm-next sound like a new module or something similar, so I just wanted to be sure, to have it activated.
17:14imirkin_: most branches that feed into linus's tree are called <subsystem>-next
17:15imirkin_: [and are continuously integrated into something called "linux-next", which just merges all those branches together]
17:15Vollstrecker: k, kernel-development is something I never came in touch with.
17:15mooch2: mwk: i fixed moar of your tests
17:16imirkin_: yeah, it's a complicated beast - tons of people working on it
17:18Vollstrecker: Like on other projects with some more devs. But most projects I work on, just use branches on the same repo. Most of them are named like the feature they want to implement. Likle cmake or kf5-port.
17:18Vollstrecker: I'll try on wednesday and report back then.
17:18imirkin_: yeah. as you might imagine, that doesn't scale to thousands of developers. and it requires shared permissions on everything.
17:19imirkin_: but that approach works great for smaller projects
17:21mwk: mooch2: uh, what did you fix?
17:22mooch2: mwk: scan test
17:22mooch2: in my emulators
17:22mooch2: god, i can't type lol
17:23mwk: I thought you found a bug in one of the tests :)
17:25mooch2: i'm just applying the knowledge from your tests to my emulator!
21:34karolherbst: Lekensteyn: ping on 99147
21:57Lekensteyn: karolherbst: pong