| kgunn | RAOF: anything noteworthy about xserver mm 14 & intel mm7 ? | 00:05 |
|---|---|---|
| RAOF | I moved a little code from intel to the xserver so that ati & nouveau are less work, and intel mm7 might render correctly in situations where mm6 didn't? | 00:06 |
| kgunn | ah,....i see buffer stride via the interface | 00:07 |
| RAOF | Yeah. | 00:09 |
| RAOF | You know what would be awesome? If our acceptance tests weren't riddled with non-deterministic failures :( | 00:10 |
| robert_ancell | thomi, ah, xrandr is considered a bit unstable | 00:10 |
| thomi | ugh | 00:11 |
| RAOF | thomi: Also, that check will become incorrect as soon as I create outputs with correct names (like HDMI-1 and eDP-1, etc) | 00:18 |
| thomi | so, what should it be doind? | 00:19 |
| thomi | *doing | 00:19 |
| RAOF | ‘grep "LoadModule.*xmir" /var/log/Xorg.${DISPLAY#:}.log’ is reasonable. | 00:21 |
| thomi | RAOF: thanks | 00:23 |
| thomi | robert_ancell: that fix is now in place - should I run the tests again? | 00:23 |
| robert_ancell | thomi, please do | 00:23 |
| thomi | robert_ancell: it seems like some jobs are already running :-/ | 00:24 |
| robert_ancell | thomi, I started it earlier, some might not have completed | 00:24 |
| thomi | should I kill them, or wait? | 00:24 |
| robert_ancell | thomi, kill them | 00:25 |
| thomi | ok, they're running again | 00:26 |
| * RAOF wonders whether he should set up an android test environment or just wait the 30minutes for Jenkins to run the tests... | 01:16 | |
| RAOF | Now really isn't the time, but we should totally rewrite cross-compile-chroot to use debootstrap and not be a huge pile of hack. | 01:36 |
| duflu | I'd just like a script that I didn't have to Ctrl+C part way through to use effectively | 01:40 |
| duflu | Though, I also don't have an N4 right now :/ | 01:41 |
| duflu | Are we waiting on anything to get the bypass patch back in the PPA for testing? | 01:44 |
| duflu | robert_ancell, RAOF ^ | 01:45 |
| RAOF | We should probably reverse copy from qa-testing2 to qu-testing now that MM is pretty much good in qa-testing2 | 01:52 |
| duflu | RAOF: Did you try ignoring buffer age yet? | 02:01 |
| RAOF | duflu: Yes. I was just about to say that it doesn't help. | 02:02 |
| RAOF | :) | 02:02 |
| duflu | Fark. Well at least we know it's not from bypass. Back to square one | 02:02 |
| RAOF | It's going to be the compositor displaying buffers out of order again. | 02:03 |
| duflu | RAOF: I am struggling to find any way to reproduce it with the tools in lp:mir alone. Being able to reproduce it would be a huge step | 02:04 |
| duflu | lp:mir is still /too flawless/. There's something our demos are not doing to trigger the bug | 02:05 |
| duflu | RAOF: Can you please triple check going age-less? I don't want to spent more days in that rabbit hole accidentally... | 02:06 |
| RAOF | Ok | 02:07 |
| RAOF | As I say, my bet is that we're going to want to annotate XMir with the buffer ID its submitting and then print out the buffer ID the compositor is drawing. | 02:10 |
| duflu | RAOF: That's feasible | 02:13 |
| duflu | Though we are almost certain already that it's the wrong order. The how and why is important | 02:14 |
| duflu | And how to reproduce it with lp:mir servers/clients only | 02:14 |
| robert_ancell | duflu, last I heard from kgunn and olli, yes | 02:30 |
| robert_ancell | duflu, sorry, "back into the PPA" - do you mean the multi-monitor PPA? | 02:31 |
| * RAOF just realises that this isn't a good test; it's going to update every frame regardless of damage, so I won't see any glitches easily | 02:35 | |
| duflu | robert_ancell: Yes qa-testing*. If there are any bugs then someone needs to tell me | 02:36 |
| robert_ancell | duflu, at the moment we just want to be sure mm works before combining it with bypass | 02:38 |
| duflu | robert_ancell: No problem. I only feared that some miscommunication about it being hideously broken may have occurred | 02:40 |
| robert_ancell | duflu, does using bypass together amplify some bug still? | 02:41 |
| duflu | robert_ancell: For nouveau/radeon I think. Can only test nouveau myself. I have some ideas for how to improve nouveau, but also think XMir won't trigger the issue | 02:41 |
| RAOF | duflu: Absolutely positively super triple-dog-sure that buffer age isn't the problem. I can still reproduce when doing a fullscreen blit on all damage. | 02:44 |
| duflu | RAOF: Ok, ta | 02:45 |
| RAOF | Huh. It's actually *two* frames behind! | 02:46 |
| * RAOF types 123 into an xterm, and sees ‘1’ | 02:47 | |
| duflu | Hmm, I wonder what Mir clients look like when the bug is occurring | 02:49 |
| RAOF | Probably roughly normal, because they almost all buffer swap at vsync? | 02:50 |
| RAOF | Only fingerpaint is likely to show anything, right? | 02:50 |
| duflu | RAOF: Probably, but does it get input? I'll try | 02:51 |
| duflu | Oh no, I can't the output_id fix isn't in the PPA yet | 02:51 |
| duflu | RAOF: I'm not sure now. Is it only lag or wrong order too? | 02:52 |
| RAOF | On the second head it seems to be purely lag. | 02:53 |
| duflu | RAOF: Hmm, hold a key down and sometimes you do see the future for a split second. That's wrong order | 02:53 |
| RAOF | Ah, yes. | 02:53 |
| RAOF | There we go. | 02:53 |
| duflu | Should we say seeing the future is a *feature*? | 02:54 |
| RAOF | Lag *and* out of order :) | 02:54 |
| duflu | Interestingly, one monitor is bug-free | 02:54 |
| RAOF | Yeah. We fixed the "only one surface buffer order presentation" problem :/ | 02:54 |
| duflu | OK, I have some good hints to work with | 02:55 |
| duflu | RAOF: Have you seen any order problems with just one output? | 02:56 |
| RAOF | No | 02:57 |
| * RAOF luncheons | 02:59 | |
| kgunn | duflu: robert_ancell ...yeah it was testing from the boston 8...which i think all turned out ok...altho, now, we need to "make it work" with multimon | 03:05 |
| kgunn | i'll defer to you guys what order things need to land... | 03:06 |
| robert_ancell | kgunn, duflu, I vote we land bypass now | 03:06 |
| duflu | robert_ancell: I know of no issues, assuming xmir doesn't trigger bug 1211700 for nouveau. Which I can't test due to XMir and nouveau not being on the same machines | 03:08 |
| ubot5 | bug 1211700 in Mir "[radeon] [nouveau] Unthrottled EGL clients cause Mir to slow, sometimes to a halt" [Undecided,New] https://launchpad.net/bugs/1211700 | 03:08 |
| kgunn | robert_ancell: so...wrt multimon ppa....we just make sure not to let mir get rebuilt once its in archive ? | 03:09 |
| robert_ancell | kgunn, we can make an inverse bypass branch if necessary for now | 03:09 |
| duflu | robert_ancell: Do we need an env var to control it in case? | 03:10 |
| robert_ancell | duflu, I wasn't aware it could be switched off - there may be a case for an option to disable it then | 03:10 |
| kgunn | duflu: i personally like that idea...we had one in android & used it often for debug | 03:10 |
| duflu | OK, will hack the option into the bypass branch first | 03:11 |
| kgunn | if its low investment of ur time | 03:11 |
| duflu | It's trivial | 03:11 |
| kgunn | cool | 03:13 |
| robert_ancell | kgunn, thomi, do you have the numbers for the bypass test? | 03:14 |
| kgunn | robert_ancell: thomi ...http://10.97.2.12:8080/view/qa-ppa/ | 03:16 |
| kgunn | so you kinda have to dig a little | 03:16 |
| kgunn | nothing looks completely amiss | 03:16 |
| robert_ancell | kgunn, yeah, wondering if there's anything to copy and paste into the MP | 03:17 |
| robert_ancell | brb | 03:19 |
| duflu | kgunn, robert_ancell: OK you can disable it with MIR_BYPASS=0 | 03:23 |
| robert_ancell | duflu, awesome | 03:24 |
| robert_ancell | duflu, did you consider a command line flag? Then it can be disabled by either a flag or an env variable | 03:24 |
| duflu | robert_ancell: No... would that set the environment internally? If not then there's a lot of wiring up that would require | 03:25 |
| robert_ancell | duflu, all command line flags can be set with MIR_SERVER_FOO for --foo | 03:25 |
| duflu | robert_ancell: That doesn't have to be redone for each server right? | 03:26 |
| robert_ancell | duflu, nope, they all get that | 03:26 |
| kgunn | robert_ancell: so...should we line up the canonical folks tonight we want to give multimon a shot their morning ?? | 03:28 |
| robert_ancell | kgunn, RAOF, it only works for intel right? | 03:28 |
| kgunn | or should we wait a bit ? | 03:28 |
| duflu | Now it's a non-trivial exercise :/ | 03:28 |
| kgunn | robert_ancell: i thot you were trying to run it on the boston 8 earlier ?...did ati/nouveau fail ? | 03:29 |
| duflu | robert_ancell: Too complex to rush in such logic right now. It's pretty hidden so we can change it later | 03:29 |
| duflu | ... because getting command line option values seems to create complex class dependencies | 03:30 |
| robert_ancell | kgunn, we don't have the drivers working for ati/nouveau yet afaik. And the Boston 8 is failing at the moment, seems to be a problem in the test script - thomi is looking at it | 03:30 |
| thomi | robert_ancell: re-running with some tweaks to the test script | 03:34 |
| RAOF | robert_ancell: ati & nouveau should work, but I haven't tested them. | 03:35 |
| kgunn | cool...so we could just line up the internal testers w reckless abandon | 03:36 |
| RAOF | Yup. | 03:38 |
| kgunn | thomi: think we could get a sanity (e.g. does it boot) on ati/nouveau within an hour ? | 03:38 |
| thomi | on the boston 8? | 03:39 |
| thomi | I can just run them without the test, if you like | 03:39 |
| kgunn | yes...or any for that mattter | 03:39 |
| RAOF | Yes, that would be nice. | 03:39 |
| thomi | ...do we expect it to not boot!? | 03:40 |
| kgunn | yeah...i just don't want to tell people to test w/o having some idea of what will happen | 03:40 |
| RAOF | Oh, I expect it to boot, but it *might* not bring up X | 03:40 |
| kgunn | :) | 03:40 |
| kgunn | just a little thing like that | 03:40 |
| RAOF | I don't *think* that there's anything wrong with the changes, but I haven't tested them :) | 03:40 |
| kgunn | so yeah..boot to usable ui is the litmus | 03:40 |
| thomi | heh, would be a lot easier if I was in the lab, but I can kick it off after the current test runs | 03:42 |
| duflu | Hmm, how come USC's XMir is frozen while I run native Mir apps on top? It should render both simultaneously, like mir_demo_server_shell does | 03:45 |
| RAOF | Output change? | 03:47 |
| RAOF | USC changes output layout when I fire up mir_demo_client_egltriangle. | 03:47 |
| RAOF | Which is expected behaviour; resolution is per-session. | 03:48 |
| duflu | RAOF: But XMir is still composited and visible. Just frozen when a Mir client is focussed. | 03:49 |
| duflu | If it's composited and visible, it should keep rendering | 03:49 |
| kgunn | bbiab | 04:04 |
| robert_ancell | RAOF, so do you have a multi-monitor desktop working at the moment? | 04:10 |
| RAOF | Yes. | 04:10 |
| robert_ancell | I can't get spanning working in Unity and while playing with it I just end up with a black screen | 04:10 |
| RAOF | qa-testing2 works fine for me. | 04:10 |
| RAOF | Do you have delicious logs? | 04:10 |
| robert_ancell | what would you like? I've just restarted into a fresh session | 04:11 |
| RAOF | Xorg log, unity-system-compositor log, & lightdm log? | 04:12 |
| robert_ancell | brb | 04:12 |
| thomi | bah, jobs still failing | 04:14 |
| RAOF | robert_ancell: Winning? | 04:20 |
| robert_ancell | RAOF, ok, lets start with what I see. | 04:21 |
| RAOF | robert_ancell: Winning! https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 | 04:21 |
| robert_ancell | RAOF, 1. Log into Unity without monitor connected, all good | 04:21 |
| robert_ancell | 2. Connect monitor | 04:21 |
| robert_ancell | 3. See a pile of flickering, then second monitor shows mirrored display | 04:22 |
| robert_ancell | 4. BUT, the second display is taller and thinner than my laptop one so the desktop is cropped and extended | 04:22 |
| robert_ancell | 5. Can't launch any new X apps | 04:22 |
| RAOF | Good so far. I'm not sure why it flickers so much - I think that Mir is doing more modesetting than necessary. | 04:23 |
| robert_ancell | the X log shows ~1.6 million lines of "_XSERVTransSocketUNIXAccept: accept() failed" | 04:23 |
| RAOF | What Mir do you have? That means it doesn't have https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 merged into it. | 04:23 |
| robert_ancell | ah | 04:24 |
| RAOF | (Mir is flooding the server with fds until accept() can't open a new fd) | 04:24 |
| robert_ancell | I have qa-testing pinned, not qa-testing2 | 04:24 |
| robert_ancell | ok, I'll rinse and repeat | 04:24 |
| thomi | kgunn: robert_ancell: I just updated the ppa2 job to not actually run the tests, so when the current jobs end, you can re-kick off the run_all job and you'll have your boot test | 04:25 |
| robert_ancell | thomi, ta | 04:25 |
| thomi | I gotta go lie down though, I'm sick :( | 04:25 |
| thomi | will be back later maybe | 04:25 |
| robert_ancell | thomi, get well! | 04:29 |
| robert_ancell | RAOF, Do you know if SwapIntervalSignalTest works with fix-multi-surface-buffer-tracking? i.e. is alan_g's problem resolved? | 04:29 |
| robert_ancell | duflu, can you review that too asap if you need to? | 04:29 |
| RAOF | robert_ancell: Yes, it's resolved. | 04:29 |
| RAOF | robert_ancell: (As you can see from the tests all passing ☺) | 04:29 |
| duflu | robert_ancell: Yeah. I also have a reasonable theory for bad buffer ordering now. But first, lunch, postoffice, coffee | 04:29 |
| RAOF | I'm going out for a couple of hours; I'll get back to testing once I'm back. | 04:31 |
| robert_ancell | duflu, do you want to delay landing this? | 04:32 |
| robert_ancell | RAOF, cool, aside from the known lagging issue it works for me! | 04:37 |
| duflu | robert_ancell, I don't want to delay anything... Just going to lunch | 04:40 |
| robert_ancell | duflu, I mean, should we wait for you or you don't plan on reviewing | 04:41 |
| robert_ancell | kgunn, do you have that list of internal testers for multi-monitor? I'm having trouble finding it in my email | 04:44 |
| kgunn | robert_ancell: i do ...i crafted a setup email just now | 04:50 |
| robert_ancell | ok, cool | 04:51 |
| kgunn | robert_ancell: i'm gonna send...please read, then just followup with expectations on ati/nouveau | 04:54 |
| robert_ancell | RAOF, ati/nouveau are expected to work, just no-one has tested them right? | 04:56 |
| kgunn | robert_ancell: yeah...that's what he was saying | 04:57 |
| robert_ancell | kgunn, the Boston 8 tests are all failing again | 04:57 |
| kgunn | :-| | 04:57 |
| robert_ancell | kgunn, can you see those jenkins logs? | 04:57 |
| kgunn | http://10.97.2.12:8080/view/qa-ppa2/ | 04:58 |
| robert_ancell | yeah | 04:58 |
| kgunn | i don't get it tho...it says intel is failing but the results look good | 05:00 |
| kgunn | on both resolutions | 05:00 |
| robert_ancell | kgunn, where are you looking at results? | 05:01 |
| kgunn | robert_ancell: here...http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/ws/results/test-results/ | 05:01 |
| kgunn | then drill into each folder marked for resolution... | 05:01 |
| kgunn | then composite.xml | 05:02 |
| kgunn | i'm gonna head off to bed....see you tomorrow | 05:02 |
| robert_ancell | later | 05:02 |
| kgunn | tvoss: i'll see you in ~9 hrs w/ olli :) | 05:02 |
| tvoss | kgunn, ack, later | 05:02 |
| robert_ancell | RAOF, so you think ati works, but you haven't tested it? You have some ati hardware right? | 05:18 |
| robert_ancell | tvoss, duflu, RAOF etc, can I get a review on https://code.launchpad.net/~robert-ancell/unity-system-compositor/fix-usc-shell-wrapper/+merge/181942 please? | 05:23 |
| robert_ancell | I'm finishing up for the night, any last requests? | 05:27 |
| duflu | robert_ancell: Relax? | 05:28 |
| robert_ancell | that would be awesome | 05:28 |
| tvoss | duflu, ping | 05:36 |
| duflu | tvoss, pong | 05:36 |
| RAOF | Ok. | 07:01 |
| RAOF | Let's test that radeon boots, at least. | 07:01 |
| duflu | Argh. I _still_ can't find a theoretical reason for bad frame ordering. The algorithm's designed to make it (theoretically) impossible | 07:04 |
| dholbach | good morning | 07:05 |
| RAOF | Good morning. | 07:07 |
| RAOF | Ah. I seem to have managed to break radeon. Excellent. | 07:07 |
| dholbach | hey RAOF | 07:07 |
| mlankhorst | perfect | 07:09 |
| mlankhorst | duflu: maybe it's not the theory, it's the implementation? :P | 07:09 |
| duflu | mlankhorst: Yeah, which is why I'm trying to find bugs still | 07:10 |
| mlankhorst | RAOF: perfect, can I look at it? :P | 07:10 |
| RAOF | mlankhorst: You're welcome to. It's... oh, not hosted in any public git tree. | 07:11 |
| RAOF | Let me fix that :) | 07:11 |
| RAOF | I've probably set the stride of the thingy wrong. | 07:11 |
| mlankhorst | yeah those thingies can get picky | 07:12 |
| RAOF | mlankhorst: github.com/RAOF/xf86-video-ati, branch "foo" | 07:18 |
| mlankhorst | RAOF: what mir branch etc do I need for that? or ppa | 07:18 |
| RAOF | You need ppa:mir-team/qa-testing2 | 07:19 |
| RAOF | Or github.com/RAOF/xserver , branch vladmir-upstreaming | 07:19 |
| mlankhorst | ah | 07:20 |
| RAOF | mlankhorst: I'll have set devKind incorrectly in the ModifyPixmapHeader call. | 07:27 |
| RAOF | Becasue I'm still not entirely sure what WTH that's meant to be :) | 07:27 |
| RAOF | mlankhorst: Oh, I may have done the same for nouveau... | 07:28 |
| === kode54 is now known as ]k[ | ||
| RAOF | mlankhorst: Do you remember offhand what devKind is meant to be for radeon? | 07:34 |
| RAOF | Hm. It *is* meant to be stride. | 07:35 |
| mlankhorst | RAOF: it's stride for all ddx iirc | 07:49 |
| RAOF | Then I broke it somewhere else :/ | 07:49 |
| mlankhorst | yeah I'll take a look | 07:49 |
| mlankhorst | power just cut out :/ | 07:49 |
| mlankhorst | for like 5 minutes or so | 07:50 |
| tvoss__ | mlankhorst, in your place? | 07:52 |
| === ]k[ is now known as kode54 | ||
| mlankhorst | yeah | 07:56 |
| mlankhorst | RAOF: do you get something like this? | 08:12 |
| mlankhorst | [ 403.880155] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9 | 08:12 |
| mlankhorst | [ 403.880435] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! | 08:12 |
| duflu | Sigh. We may yet need a universal frame counter to throttle clients accurately under multimonitor | 08:12 |
| duflu | Wait a minute... what is "accurate"? | 08:13 |
| duflu | Surely if your client doesn't do "accurate" timing and relies on vsync then 120Hz with two monitors is not necessarily wrong :/ | 08:13 |
| duflu | Hmm | 08:13 |
| mlankhorst | duflu: that is assuming both monitors have the same scanrate | 08:15 |
| duflu | mlankhorst: I mean generally sum of all | 08:15 |
| duflu | I think we've been trying to meet a requirement that doesn't really exist... | 08:16 |
| mlankhorst | RAOF: lol | 08:16 |
| mlankhorst | [ 595.892399] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:850 texture bo too small (layer size 5299200, offset 0, max layer 1, depth 1, bo size 12288) (1472 900) | 08:16 |
| mlankhorst | combined with the previous errors it looks like your handles are corrupted :P | 08:19 |
| mlankhorst | + if (!pScreen->ModifyPixmapHeader(dst, | 08:22 |
| mlankhorst | -+ pScrn->virtualX, pScrn->virtualY, | 08:22 |
| mlankhorst | ++ output_box->x2 - output_box->x1, | 08:22 |
| mlankhorst | ++ output_box->y2 - output_box->y1, | 08:22 |
| mlankhorst | looks wrong.. | 08:22 |
| mlankhorst | hm and the last error might be from freeing a buffer | 08:29 |
| hikiko | hello :) could someone review this branch: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 if not busy? | 08:33 |
| mlankhorst | RAOF: with valgrind I seem to get more errors :P | 08:34 |
| mlankhorst | definitely looks like the bo's get unreffed before being used.. | 08:35 |
| RAOF | mlankhorst: That seems... wat? The changes shouldn't change when the bos get unreffed! | 08:37 |
| mlankhorst | RAOF: well from the dmesg I'm guessing that somewhere something gets freed before it should | 08:42 |
| mlankhorst | if i run things with valgrind I end up with Xorg failing in random random crashes | 08:44 |
| mlankhorst | s/random.*/random places/ | 08:44 |
| RAOF | mlankhorst: Oh, that reminds me. I should push the xf86-video-intel change to actually enable the valgrind support. | 08:48 |
| mlankhorst | wasn't --enable-valgrind already added, or did you redisable it? | 08:49 |
| RAOF | No, it's enabled, but only if DEB_HOST_ARCH == linux | 08:50 |
| RAOF | But DEB_HOST_ARCH is never linux; you misspelt DEB_HOST_ARCH_OS | 08:50 |
| mlankhorst | oops | 08:51 |
| mlankhorst | RAOF: anyway I'm getting some weirdness that indicates a flink leak, though. but no clue as to where it comes from yet.. | 08:55 |
| RAOF | Colour me confused, then. | 08:55 |
| mlankhorst | erm I mean you're probably freeing something twice | 08:55 |
| mlankhorst | or before using it | 08:55 |
| mlankhorst | or a particularly nasty kernel corruption.. I'll try on my older card | 09:02 |
| mlankhorst | RAOF: were you getting the same kind of errors? | 09:04 |
| RAOF | mlankhorst: Hm, no. | 09:07 |
| RAOF | I don't get any valgrind errors that aren't either unrelated (hello, writev!) or a couple of the harmless "I don't understand your ioctls" errors. | 09:09 |
| mlankhorst | I'm getting tons of crap like this | 09:09 |
| mlankhorst | [ 99.170371] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! | 09:09 |
| mlankhorst | [ 99.178895] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9 | 09:09 |
| mlankhorst | and | 09:09 |
| mlankhorst | [ 101.124015] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:476 cb[0] bo too small (layer size 6144, offset 0, max layer 1, bo size 4096, slice 23) | 09:09 |
| mlankhorst | [ 101.124021] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:480 problematic surf: (64 24) (0 4 1 0 0 4 3) | 09:10 |
| RAOF | Ah, yes. I see those. | 09:10 |
| mlankhorst | which makes me think that some stuff gets freed by the driver before submitting the commands | 09:10 |
| RAOF | Ah, fair enough. | 09:11 |
| * RAOF was confused about your valgrind comment. | 09:11 | |
| mlankhorst | RAOF: well I get some memcpy crashes from valgrind | 09:12 |
| mlankhorst | but nothing pointing towards what is going on | 09:12 |
| RAOF | Huh, really? | 09:13 |
| RAOF | memcpy? | 09:13 |
| mlankhorst | RAOF: does the root window have damage tracking after a resize event? | 09:14 |
| RAOF | Yes. | 09:14 |
| RAOF | But we should be disabling everything that has damage associated with the screen pixmap before resizing. | 09:14 |
| RAOF | 'cause we throw away the screen pixmap on resize, but not the root window. | 09:15 |
| mlankhorst | .. do you? :p | 09:15 |
| RAOF | I'm reasonably sure? | 09:18 |
| mlankhorst | hm good enough | 09:18 |
| RAOF | Anyway, resize isn't called in xserver startup? | 09:18 |
| mlankhorst | I'm trying to figure out what is going on there though | 09:19 |
| RAOF | What's your memcpy crash, anyway? | 09:21 |
| duflu | Woo! Perfect multimonitor frame sync with no timers! | 09:26 |
| mlankhorst | RAOF: never the same twice :/ | 09:29 |
| mlankhorst | but usually exa related | 09:29 |
| mlankhorst | actually always the same it seems, it's from fallback call. same thing that happens when acceleration in nouveau fails | 09:30 |
| mlankhorst | and preceded by failed to map pixmap: -2 | 09:30 |
| mlankhorst | hm from procRenderCreateCursor.. | 09:31 |
| mlankhorst | http://paste.debian.net/30292/ with memory summary removed | 09:33 |
| mlankhorst | RAOF: it worked on intel right? | 09:35 |
| RAOF | Yeah, works on intel. | 09:35 |
| mlankhorst | RAOF: implement shadowfb call :P | 09:35 |
| duflu | Well, actually, my sync is temporarily lost when VT switching, but it comes back eventually | 09:35 |
| RAOF | Also, I *don't* see that CreateCursor crash. | 09:35 |
| mlankhorst | hm actually it wouldn't help | 09:36 |
| mlankhorst | it's falling back to downloading to screen because the mapping was failing | 09:36 |
| duflu | You know, it's rather hard to create visual glitches when you're triple buffering. I never realized just how hard... | 09:37 |
| mlankhorst | it's easy if you relax the restriction and allow them to be fatal :P | 09:44 |
| RAOF | Heh | 09:48 |
| mlankhorst | RAOF: also curious it looks like xmir_copy_to_mir was wrong in another place | 09:58 |
| RAOF | Oh? | 09:59 |
| mlankhorst | you set dst x / y to 0 0, should probably be the same as src x y | 09:59 |
| RAOF | dst x/y is not location in the destination buffer? | 10:00 |
| mlankhorst | it is | 10:00 |
| RAOF | Then why wouldn't I want it to be 0 0? | 10:00 |
| mlankhorst | but I'm guessing the destination buffer is full sized? | 10:00 |
| RAOF | No, the destination buffer is output-sized. | 10:00 |
| RAOF | Welcome to the poor-man's Shatter. | 10:00 |
| mlankhorst | ah.. | 10:01 |
| mlankhorst | RAOF: you allocate a single bo for the entire screen, but each output uses a chunk of it? | 10:01 |
| RAOF | There's a single bo for the ScreenPixmap. | 10:02 |
| RAOF | But we copy each region that corresponds to an output into a different xmir_window | 10:02 |
| mlankhorst | nasty | 10:03 |
| RAOF | Or, perhaps more understandably - each enabled xf86Crtc has an associated xmir_window, with a MirSurface, and we copy from the root window into that surface. | 10:03 |
| RAOF | Eh, I don't think it's particularly nastier than having a single framebuffer surface and copying the whole root window into it. | 10:04 |
| mlankhorst | I don't really see where this particular error is coming from, what is your failure mode? | 10:09 |
| RAOF | Of *course* I don't see this crash under gdb & mir_demo_server_shell! | 10:10 |
| RAOF | BAH. | 10:10 |
| mlankhorst | ..? | 10:11 |
| mlankhorst | and I'm killing off the dup syscall. I'll just set fd to negative, and use that internally to say 'do not close after opening' :P | 10:13 |
| RAOF | mlankhorst: I can, apparently, quite happily run radeon under mir_demo_server_shell in gdb. | 10:14 |
| RAOF | No crashes, no madness... | 10:15 |
| RAOF | To be fair I'm not *actually* looking at the display; it's upstairs, so it might be entirely wrong ☺ | 10:15 |
| tvoss__ | RAOF, rofl | 10:15 |
| mlankhorst | you're like those tv commercials where they put 'not showing the actual product' in small letters on the bottom | 10:17 |
| mlankhorst | RAOF: is it just the xserver, or a full session? | 10:22 |
| RAOF | Just the X server. | 10:22 |
| mlankhorst | well duh :P | 10:22 |
| RAOF | Why duh? | 10:22 |
| mlankhorst | see if it survives this: DISPLAY=:0 XDESKTOP_SESSION=ubuntu /etc/X11/Xsession | 10:22 |
| mlankhorst | erm | 10:23 |
| mlankhorst | DESKTOP_SESSION* | 10:23 |
| RAOF | Hm. dmesg does not survive DISPLAY=:33 glxgears :) | 10:23 |
| mlankhorst | hah | 10:23 |
| RAOF | [ 1806.614838] [drm:r600_cs_common_vline_parse] *ERROR* cannot find crtc 1436857232 | 10:23 |
| RAOF | I'm not surprised it can't find it! | 10:24 |
| mlankhorst | or are you? DUN DUN DUUUN | 10:24 |
| mlankhorst | 55a4b390 | 10:24 |
| mlankhorst | RAOF: ah right, it's calling evergreen_cp_wait_vline_sync | 10:31 |
| RAOF | That seems unlikely to work. I thought I disabled vsyncing? | 10:31 |
| mlankhorst | all the calls are hidden behind accel_state->vsync | 10:33 |
| tvoss__ | okay, time to take care of my visum for china | 10:34 |
| RAOF | Oh, dear. | 10:34 |
| RAOF | No, I undisabled vsynching when I shoved a non-null driver private in xf86Crtc. | 10:35 |
| mlankhorst | RAOF: erm it looks like the calls are only emitted if the driver has accel_state->vsync set though | 10:36 |
| * tvoss__ thinks about undisabled | 10:36 | |
| RAOF | mlankhorst: Try bailing early with NULL from radeon_pick_best_crtc (in radeon_video.c)? | 10:39 |
| RAOF | Ok, time for me to sleep | 10:40 |
| mlankhorst | that's xv stuff.. | 10:53 |
| mlankhorst | RAOF: did you explicitly enable vsync or something? | 10:54 |
| mlankhorst | looks like vsync is disabled in radeon unless you explicitly enable it | 10:55 |
| mlankhorst | hm indeed, same issue here :p | 11:00 |
| mlankhorst | radeon_dri2.c: info->accel_state->vsync = info->swapBuffersWait; | 11:02 |
| mlankhorst | - OPTION_SWAPBUFFERS_WAIT, TRUE); | 11:02 |
| mlankhorst | + OPTION_SWAPBUFFERS_WAIT, !xorgMir); | 11:03 |
| mlankhorst | well that gets rid of 1 source of errors.. | 11:04 |
| === hikiko is now known as hikiko|lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| mlankhorst | meh on the crashing call.. | 12:07 |
| mlankhorst | (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(src))->bo | 12:07 |
| mlankhorst | $2 = {base = {ptr = 0x0, flags = 0, handle = 1, size = 5652480, alignment = 16384, domains = 4, cref = 3, bom = 0x5555559d81b0, space_accounted = 0, referenced_in_cs = 0}, name = 0, map_count = 0, reloc_in_cs = { | 12:07 |
| mlankhorst | atomic = 0}, priv_ptr = 0x0} | 12:07 |
| mlankhorst | (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(dst))->bo | 12:07 |
| mlankhorst | $3 = {base = {ptr = 0x0, flags = 0, handle = 9, size = 5299200, alignment = 0, domains = 2, cref = 2, bom = 0x5555559d81b0, space_accounted = 0, referenced_in_cs = 0}, name = 9, map_count = 0, reloc_in_cs = { | 12:07 |
| mlankhorst | atomic = 0}, priv_ptr = 0x0} | 12:07 |
| mlankhorst | [ 491.685460] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9 | 12:07 |
| mlankhorst | it still has refcount set >:( | 12:08 |
| === chihchun is now known as chihchun_afk | ||
| kgunn | duflu: so is that branch good to go ?....e.g. add it to qa-testing2? or just build local for more confidence? | 12:17 |
| kgunn | mlankhorst: i see chris went to bed, so does ati work with multimon ? (i'm guessing no...) | 13:02 |
| mlankhorst | kgunn: it sort of looks like I'm hitting a kernel bug | 13:03 |
| kgunn | mlankhorst: does it work on standard xmir (w.o multimon?) | 13:04 |
| mlankhorst | hm I ws trying to rollback kernel, I guess standard xmir would be easier to test | 13:05 |
| kgunn | mlankhorst: glad i asked :) save you some effort | 13:05 |
| mlankhorst | hm I guess that works, weird stuff.. | 13:14 |
| kgunn | mlankhorst: so xmir in archive works...but xmir (multimon, qa-testing2 ppa) does not ? | 13:17 |
| mlankhorst | yeah | 13:18 |
| kgunn | meaning...can't boot to unity ? or cycles endlessly on greeter ?...curious the symptom/end user result | 13:18 |
| mlankhorst | right now I just forced it to crash, saves times | 13:18 |
| kgunn | :) | 13:18 |
| kgunn | ricmm: i know you're swamped....had a chance to try xmir-multimonitor? | 13:19 |
| kgunn | rsalveti: ^ | 13:19 |
| rsalveti | kgunn: will try today, have an ati board here | 13:20 |
| rsalveti | 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] | 13:20 |
| kgunn | rsalveti: well... :) ...i'm sure you can see mlankhorst 's posts above | 13:21 |
| rsalveti | but is that the same board? | 13:21 |
| rsalveti | mine is quite old | 13:21 |
| rsalveti | but guess I'd get the same crash | 13:22 |
| rsalveti | we'll see | 13:22 |
| ricmm | kgunn: negativo | 13:23 |
| ricmm | and I actually cant, I dont have a second monitor | 13:23 |
| ricmm | :( | 13:23 |
| mlankhorst | not required | 13:26 |
| mlankhorst | I was testing a single monitor setup | 13:26 |
| kgunn | ricmm: so it would still be useful to see if you can boot into a useable unity session even on 1 monitor | 13:27 |
| kgunn | RAOF: duflu ....just sharing, seems nvidia at least did get to run http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-nvidia-gt440-le/ws/results/800x600.output | 13:53 |
| kgunn | altho...looks like it hung or bailed on the last test (unsure) | 13:53 |
| kgunn | ....looking from syslog...whoopsie might have gotten in the way ? | 13:54 |
| kgunn | mlankhorst: ^....just sharing...no action | 13:54 |
| mlankhorst | nouveau is easier to test though :P | 13:54 |
| kgunn | thomi: robotfuel ^ | 13:54 |
| robotfuel | kgunn: I am watching some of the jobs now, I think some of the failures are because of the install phase package names had changed. | 13:55 |
| robotfuel | kgunn: I didn't setup the ppa2 jobs | 13:56 |
| kgunn | robotfuel: thanks....actually....i see a radeon run now too :) | 13:56 |
| kgunn | http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/ | 13:56 |
| robotfuel | kgunn: it looks like package name issue is fixed but hasn't been run, I can also disable whoopsie | 13:57 |
| kgunn | robotfuel: is that your subtle way of blaming the kiwi's :) | 13:57 |
| kgunn | mlankhorst: http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/ | 13:57 |
| kgunn | so that's interesting....that actually ran | 13:57 |
| mlankhorst | kgunn: yeah but I'm on drm-next | 13:57 |
| kgunn | mlankhorst: oh... | 13:58 |
| robotfuel | kgunn: this one also looked like openarena finished http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd5750-le/4/artifact/results/ | 13:58 |
| kgunn | mlankhorst: that was lost on me...so qa-testing2 on drm-now...is ok? | 13:58 |
| mlankhorst | no idea, stupid laptop won't cooperate :P | 13:58 |
| kgunn | olli_: ^ | 13:58 |
| kgunn | olli_: so looks like nouveau & radeon are actually running | 13:58 |
| kgunn | not sure why the report says fail...but if you dig...you can see results | 13:59 |
| robotfuel | kgunn: unity-system-compositor wasn't running on that build I linked to before http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd5750-le/4/artifact/results/ps-aux.log | 14:00 |
| kgunn | robotfuel: ah...got too excited | 14:01 |
| kgunn | robotfuel: so can you confirm the following...xmir-mm (aka qa-ppa2) on ati & nouveau specifically | 14:05 |
| kgunn | robotfuel: is actually running xmir & can boot to a usable unity ui (first) | 14:05 |
| robotfuel | kgunn: unity system compositor wasn't running on the intel jobs, I am rerunning everything now, it looks like the tests were fixed 6 hours ago, but they were run 10 hours ago | 14:05 |
| kgunn | robotfuel: second, can you actually plug/unplug a second monitor monitor | 14:06 |
| kgunn | robotfuel: like manually | 14:06 |
| kgunn | robotfuel: like...as soon as you're able | 14:06 |
| robotfuel | kgunn: sure, I will drive in during lunch | 14:06 |
| kgunn | robotfuel: is there anyone in the office who could try ? | 14:06 |
| kgunn | sorry racing clock | 14:07 |
| robotfuel | rfowler might be in. | 14:07 |
| robotfuel | kgunn: which machine do you want the monitor tried on first? | 14:09 |
| kgunn | robotfuel: either... | 14:09 |
| kgunn | robotfuel: we're just looking for a sanity test of multimonitor on xmir | 14:09 |
| kgunn | robotfuel: can't seem to find anyone else in lex...so i might just be needing you to head for lunch | 14:20 |
| robotfuel | kgunn: sounds good I can head in right after a meeting I have at 11am (40 minutes) | 14:21 |
| kgunn | robotfuel: much thanks | 14:22 |
| robotfuel | kgunn: I am getting no video on the kvm on intel with the qa-testing2 ppa | 14:38 |
| mlankhorst | hm guess it's not just me then :P | 14:39 |
| kgunn | robotfuel: meaning?...like you're in the unity ui but you can play youtube videos? or just nothing? | 14:39 |
| robotfuel | kgunn: black screen | 14:39 |
| robotfuel | kgunn: no ui | 14:40 |
| kgunn | robotfuel: are the other intels the same?? | 14:40 |
| robotfuel | kgunn: yes same issue | 14:40 |
| kgunn | robotfuel: what does apt-cache policy for xserver-xorg-video-intel say ? | 14:41 |
| kgunn | robotfuel: what does apt-cache policy for unity-system-compositor say also ? | 14:41 |
| robotfuel | kgunn: the driver is the issue apt-get install unity-system-compositor didn't pull in the driver. | 14:43 |
| kgunn | robotfuel: sorry...i just have to ask...ppa pinned ? | 14:43 |
| robotfuel | kgunn: yes it's pinned | 14:44 |
| robotfuel | kgunn: unity-system-compositor is installed from the pinned ppa | 14:44 |
| robotfuel | kgunn: sudo apt-get install xserver-xorg-video-intel pulls in the driver from the pinned ppa | 14:45 |
| robotfuel | kgunn: seems like a packaging bug | 14:46 |
| kgunn | robotfuel: just curious....how so ?...i was wondering....how is it pinned ?? | 14:46 |
| kgunn | take a look at this doc | 14:46 |
| kgunn | https://docs.google.com/a/canonical.com/document/d/1hmSrL_ZqnpMo0oDf-lee22J2cJr54jWmCeziMxR131s/edit | 14:46 |
| kgunn | ^ i am wondering if you need the extra bit at the top | 14:47 |
| robotfuel | cat /etc/apt/preferences.d/50-pin-mir.pref Package: * | 14:47 |
| robotfuel | Pin: origin "private-ppa.launchpad.net" | 14:47 |
| robotfuel | Pin-Priority: 1001 | 14:47 |
| robotfuel | Package: * | 14:47 |
| robotfuel | Pin: release o=LP-PPA-mir-team-qa-testing2 | 14:47 |
| robotfuel | Pin-Priority: 1002 | 14:47 |
| kgunn | my pin is like the bottom | 14:47 |
| robotfuel | kgunn: my pin is like the bottom | 14:47 |
| kgunn | robotfuel: cool... | 14:47 |
| kgunn | so that's not it | 14:48 |
| kgunn | robotfuel: i guess you'll need to check the blasted ati/nouveaus as well... | 14:48 |
| robotfuel | kgunn: I can add the drivers to apt-get install line to get the correct driver. | 14:48 |
| mlankhorst | looks like I messed up nouveau vblank in my tree, time to retest :P | 14:48 |
| robotfuel | radeon is a black screen | 14:48 |
| kgunn | robotfuel: thanks | 14:48 |
| robotfuel | kgunn: wrong driver | 14:49 |
| mlankhorst | robotfuel: anything in dmesg? | 14:49 |
| robotfuel | kgunn: I need to update the test and re-run pulling in the driver. | 14:49 |
| robotfuel | oops mlankhorst^ | 14:49 |
| kgunn | robotfuel: no problem...and as usual...thanks for the help | 14:51 |
| mlankhorst | fwiw, same blackness here | 14:51 |
| mlankhorst | on nouveau at least | 14:52 |
| kgunn | mlankhorst: you get matches on cross check of apt-cache policy & qa-testing2 packages ? | 14:54 |
| mlankhorst | yes | 14:56 |
| kgunn | mlankhorst: does it make it to greeter ? | 14:59 |
| mlankhorst | it's black, no idea, all I know is it doesn't crash | 15:00 |
| kgunn | freaky...what does Xorg.0.log say ? | 15:01 |
| mlankhorst | nothing interesting | 15:01 |
| mlankhorst | pretends everything is fine | 15:01 |
| kgunn | mmmm...can you vt switch....then $ sudo chmod 777 /tmp/mir_socket...$ sudo mir_demo_client_egltriangle...then switch back to vt7 ? | 15:02 |
| kgunn | robotfuel: are you actually in office already ? | 15:03 |
| kgunn | must be driving | 15:03 |
| robotfuel | kgunn: no in a meeting | 15:04 |
| mlankhorst | kgunn: triangle works nicely | 15:04 |
| mlankhorst | but I like the plasma one more :p | 15:04 |
| kgunn | mlankhorst: do you see unity as a backdrop to the triangle ? | 15:04 |
| mlankhorst | no the same blackness | 15:04 |
| kgunn | huh | 15:05 |
| hikiko | mmm anyone for the meeting? | 15:05 |
| kgunn | so mir is up..u-s-c is up no problem | 15:05 |
| mlankhorst | I think RAOF needs to get back to the drawing board somehow, and review what is going on with lifetime :P | 15:05 |
| hikiko | I am alone there :) | 15:05 |
| kgunn | hikiko: uk is off today... | 15:05 |
| hikiko | oh :) i see | 15:05 |
| kgunn | hikiko: free day to focus on mir-on-mir :) | 15:05 |
| kgunn | mlankhorst: right...but this means mir is up, its like compiz failed | 15:06 |
| kgunn | mlankhorst: or...xmir failed to hook up compiz to u-s-c frontend | 15:06 |
| kgunn | mlankhorst: is there a way to verify is compiz loaded/rendered....but buffer just didnt make it to screen ? | 15:06 |
| kgunn | like there should be more than one gl client active | 15:07 |
| kgunn | 1 for mir....and 1 or more for unity/compiz | 15:07 |
| hikiko | mm then here's a quick status in case someone has time to review my branches: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications | 15:08 |
| kgunn | mlankhorst: just trying to think how to help RAOF with some usable debug | 15:08 |
| hikiko | bye! | 15:08 |
| robotfuel | kgunn: I have a black screen on radeon using http://ppa.launchpad.net/mir-team/qa-testing2/ubuntu/ saucy/main xserver-xorg-video-radeon | 15:12 |
| kgunn | robotfuel: anything interesting at the end of /var/log/Xorg.0.log ? | 15:13 |
| robotfuel | kgunn: a lot of this [ 28.871] reloc emit failure -22 (evergreen_set_render_target 318) | 15:14 |
| robotfuel | [ 28.871] reloc emit failure -22 (evergreen_cp_set_surface_sync 371) | 15:14 |
| kgunn | mlankhorst: ^ | 15:14 |
| kgunn | robotfuel: curious can you vt switch, then $ sudo chmod 777 /tmp/mir_socket | 15:15 |
| kgunn | then $sudo mir_demo_client_egltriangle...then vt switch back to vt7....and see what happens? | 15:16 |
| robotfuel | kgunn: ok | 15:16 |
| robotfuel | kgunn: vt change has a scrolling error gem object lookup failed 0xa | 15:19 |
| robotfuel | kgunn: this is on radeon | 15:19 |
| kgunn | robotfuel: got it....all good data | 15:19 |
| kgunn | robotfuel: did you do a cross-check match of packages installed vs qa-testing2 ? | 15:20 |
| robotfuel | kgunn: doing that now, it looks good so far | 15:22 |
| sil2100 | kgunn: hi! | 15:22 |
| sil2100 | kgunn: during the last mirslave run we noticed that one of the AP tests failed on both machines | 15:23 |
| sil2100 | kgunn: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1276/ | 15:23 |
| sil2100 | kgunn: not sure if that's just a flacky test or is this a real failure, but I think I'll fill in a bug anyway | 15:24 |
| kgunn | sil2100: ack... | 15:26 |
| kgunn | thomi: ^ | 15:26 |
| robotfuel | kgunn: my meeting is over I am going to drive in to lexington | 15:26 |
| kgunn | robotfuel: cool...it'll be easier for you there i'm sure...just ping me when you're ready | 15:27 |
| sil2100 | kgunn: https://bugs.launchpad.net/unity-system-compositor/+bug/1216979 | 15:31 |
| ubot5 | Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Undecided,New] | 15:32 |
| kgunn | bschaefer: hey...you got a spare set of cycles? | 16:31 |
| bschaefer | kgunn, possibly, whats up? | 16:32 |
| kgunn | bschaefer: just lookin' for a second set of eyes/attempt on nouveau and/or ati | 16:35 |
| bschaefer | kgunn, yeah I can try, I've to finish up some reviews first | 16:35 |
| kgunn | using mir-team/qa-testing2 ppa | 16:35 |
| kgunn | sure | 16:35 |
| bschaefer | cool | 16:35 |
| bschaefer | ill let you know! | 16:35 |
| kgunn | low expectations...but if you try, let me know if you boot to a usable unity (single monitor :) | 16:36 |
| bschaefer | well hopefully I can :) | 16:37 |
| robotfuel | kgunn: I'll test nvidia first with multimonitor | 16:44 |
| robotfuel | kgunn: I am in the lab | 16:45 |
| kgunn | robotfuel: cool... | 16:47 |
| kgunn | robotfuel: will be good to know if you get the same black screen on boot | 16:48 |
| jono | kgunn, on the Mir multimonitor page I see I pin: | 16:49 |
| jono | Package: * Pin: origin "private-ppa.launchpad.net" Pin-Priority: 1001 Package: * Pin: release o=LP-PPA-mir-team-qa-testing2 Pin-Priority: 1002 | 16:49 |
| jono | but it says I use the $> sudo add-apt-repository ppa:mir-team/system-compositor-testing PPA | 16:50 |
| jono | shouldn' | 16:50 |
| jono | shouldn't the pin represent that PPA? | 16:50 |
| jono | I just added the PPA and MM doesn'work for me | 16:50 |
| robotfuel | kgunn: it looks like one intel machine passed on the testing2 ppa (not a multi-monitor test) | 16:50 |
| kgunn | jono: dang it....(going to make a tshirt that says "i hate ppa's" | 16:51 |
| jono | kgunn, do I add a different PPA? | 16:51 |
| kgunn | jono: right...for now its all qa-testin2 | 16:51 |
| jono | kgunn, so do I remove the system-compositor PPA? | 16:51 |
| kgunn | when we go live to test external...we'll use system-compositor-testing | 16:51 |
| kgunn | sorry for the confusion | 16:52 |
| jono | np | 16:52 |
| jono | kgunn, we go live today, right? | 16:53 |
| jono | according to balloons | 16:53 |
| kgunn | jono: yes | 16:53 |
| jono | cool | 16:53 |
| jono | will res changes and rotation be fixed this week? | 16:53 |
| jono | brb | 16:54 |
| kgunn | robotfuel: would you mind just hotplugging a monitor into the intel machine...so when olli asks i can say...yes, robotfuel saw multimon work on the anointed machine :) | 16:56 |
| robotfuel | kgunn: will do. | 16:57 |
| robotfuel | kgunn: the nvidia machine has a black screens | 16:57 |
| robotfuel | kgunn: I'll try the vt change thing and let you know how it goes | 16:57 |
| kgunn | robotfuel: sounds intimidating :) | 16:58 |
| kgunn | robotfuel: thanks | 16:58 |
| kgunn | and check xorg.0.log if you don't mind | 16:58 |
| robotfuel | kgunn: x went to fallback mode after the vt switch | 17:01 |
| kgunn | robotfuel: ooo, well that's kinda nice | 17:02 |
| robotfuel | kgunn: fallback meaning low-graphics mode | 17:02 |
| kgunn | robotfuel: oh, nvmd that's awful | 17:02 |
| kgunn | robotfuel: Xorg.0.log ? | 17:03 |
| robotfuel | kgunn: I am grabbing that now, I'll pastebin it | 17:04 |
| kgunn | robotfuel: would be good to get one prior to vt switch (sorry to be so picky) | 17:05 |
| robotfuel | kgunn: http://pastebin.ubuntu.com/6029411/ (with vtswitch) | 17:06 |
| robotfuel | kgunn: without vtswitch http://pastebin.ubuntu.com/6029418/ | 17:08 |
| kgunn | robotfuel: more than i could hope for...putting both in the bug | 17:10 |
| robotfuel | kgunn: do you want me to use apport on the u-s-c and xorg crashes? | 17:11 |
| kgunn | that'd be good robotfuel | 17:11 |
| kgunn | robotfuel: now just need to double check the ati's....i assume black screen...but need to check xorg & try vt switch as well... | 17:13 |
| robotfuel | kgunn: ack, after I do the apport thing I'll check ati, then intel last. | 17:14 |
| kgunn | great | 17:14 |
| kgunn | robotfuel: i'll brb...gonna eat a quick lunch | 17:14 |
| kgunn | robotfuel: i'm bacl | 17:35 |
| kgunn | back even | 17:35 |
| kgunn | and...quick reboot | 17:47 |
| bschaefer | kgunn, hey, I got a black screen,but I still heard the lightdm login sound... | 18:00 |
| bschaefer | i also was getting a strange error on my tty...but its not on any logs that I can find... | 18:00 |
| * bschaefer digs for it | 18:00 | |
| robotfuel | bschaefer: something about gem object lookup failed? | 18:05 |
| bschaefer | robotfuel, yup! | 18:06 |
| bschaefer | i can't find it logged anywhere... | 18:06 |
| bschaefer | there it is: | 18:06 |
| bschaefer | kernel: [ 67.625036] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb | 18:07 |
| robotfuel | I have a 0xa on one with the kvm and 0x8 using 2 monitors | 18:07 |
| bschaefer | kernel: [ 67.628417] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb | 18:07 |
| bschaefer | kernel: [ 67.629992] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! | 18:07 |
| bschaefer | robotfuel, hmm interesting, let me try with 2 monitors, or one? I forgot if I had my other one turned on :) | 18:08 |
| bschaefer | though I don't think it matters much... | 18:10 |
| kgunn | bschaefer: thanks...adding your details to the bug | 18:11 |
| bschaefer | kgunn, my video card is: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730] | 18:11 |
| bschaefer | the 5670 one... | 18:11 |
| robotfuel | kgunn: 2 of the intel machines time out, it looks like the benchmark hung using the new driver xserver-xorg-video-intel (2:2.21.14-4ubuntu2+xmirMM7) one of them passed | 18:17 |
| kgunn | robotfuel: did woopsie interfere ? | 18:21 |
| robotfuel | kgunn: I am watching the test run now to see what happens | 18:22 |
| kgunn | robotfuel: iirc i ran...but might have been one driver before....lemme run here | 18:25 |
| kgunn | robotfuel: hmmm running openarea no prob here...2 runs, 2 diff resolutions | 18:33 |
| kgunn | robotfuel: going to try my second machine | 18:33 |
| kgunn | robotfuel: did i miss it...did you also alreday check the ati machine(s)....just looking to be conclusive on "it didn't work" :) | 18:44 |
| kgunn | robotfuel: really only need 2 questions re qa-testing2 answered now #1) result of ati machine there boot to unity (single screen) & #2) did intel support hotplug of monitor to show multimon | 18:49 |
| robotfuel | kgunn: single intel on the kvm is messed up. I am trouble shooting that now. | 18:52 |
| robotfuel | kgunn: single monitor boot to unity on ati was a black screen. | 18:53 |
| robotfuel | kgunn: I'll plug in a monitor now, they are hard to get to. | 18:53 |
| kgunn | robotfuel: you might have to "liberate" some :) | 18:54 |
| robotfuel | kgunn: the video looked tiled on the kvm, but looks ok with a monitor connected | 19:01 |
| kgunn | robotfuel: ack thanks | 19:02 |
| robotfuel | kgunn: the intel machines don't have a place for a second monitor, they only have one hdmi port, no vga or dvi | 19:26 |
| kgunn | robotfuel: haha | 19:27 |
| kgunn | you can't make this stuff up | 19:27 |
| robotfuel | kgunn: the ps-intel-3000 has a vga and display port, so I can test it on that machine. the other 2 only have hdmi | 19:30 |
| kgunn | robotfuel: that's ok...both DP and hdmi worked | 19:30 |
| robotfuel | kgunn: benchmarks are up http://reports.qa.ubuntu.com/graphics/openarena/ | 19:38 |
| kgunn | robotfuel: awesome! thanks...thanks for all the hard work that has gone (and is going) into that | 19:39 |
| robotfuel | kgunn: you can double click the bar and it will take you to the jenkins build for that run, so you can look at the log files easily. | 19:40 |
| kgunn | robotfuel: you're going to spoil us | 19:40 |
| robotfuel | kgunn: on intel xrandr is reporting 2 monitors are connected, even though only one monitor is connected | 20:14 |
| robotfuel | kgunn: I turned off the second monitor and the screen is blank now. (there was XMIR-0 and XMIR-2, I did xrandr --output XMIR-2 --off) | 20:15 |
| kgunn | robotfuel: was that using displayport ? | 20:16 |
| robotfuel | kgunn: hdmi | 20:16 |
| kgunn | hmmm...hadn't seen weirdness from hdmi yet...that's a good bug tho | 20:16 |
| kgunn | or good you caught it | 20:16 |
| robotfuel | kgunn: I resized XMIR-0 to 800x600 and it showed the 2 displays, one 800x600 and one 1024x768 display on the same monitor | 20:18 |
| robotfuel | I'll write a bug | 20:18 |
| kgunn | robotfuel: ta | 20:18 |
| === sam113101_ is now known as sam113101 | ||
| jono | kgunn, installed the PPA, a bit of screwing with different res settings but dual-screen MM working perfectly on Intel :-) | 21:25 |
| kgunn | jono: good to hear :) | 21:25 |
| jono | kgunn, my default setup before-hand had part of the image chopped off | 21:25 |
| robotfuel | kgunn: will you need me in lexington tomorrow? | 21:59 |
| kgunn | robotfuel: i don't think so... | 22:00 |
| robotfuel | kgunn: ok I won't plan on it then. I won't be there first thing in the morning, but I'll drive in if you need me there again :) | 22:02 |
| kgunn | robotfuel: hey thank you for doing it today...greatly appreciate that...i owe you abeer in a couple of weeks | 22:03 |
| * robert_ancell things kgunn is going to have a keg party :) | 22:05 | |
| kgunn | robert_ancell: shhhhh | 22:06 |
| kgunn | that or just hand out fifths of whiskey | 22:06 |
| robert_ancell | thomi, could you copy the qa-ppa2 config and make a system-compositor testing one? That way we can test any of the PPAs in Jenkins | 22:08 |
| thomi | robotfuel: can you do that with your fancy-pants script? | 22:11 |
| robotfuel | thomi: so we want new tests or we want to modify the existing tests? | 22:12 |
| thomi | robotfuel: I guess a new set | 22:12 |
| thomi | with a corresponding new kickoff job | 22:12 |
| thomi | the only difference being the ppa we add | 22:13 |
| robotfuel | thomi: ok, I'll just need to create a new branch to pull from and I'll upload that | 22:13 |
| robotfuel | thomi: I'll ping you when I am done | 22:13 |
| netlar | Do they developers of apps for Ubuntu have to port over apps to mir, and if they do not the app will run on xmir right? | 22:17 |
| robotfuel | thomi: http://10.97.2.12:8080/view/sct-ppa/ | 22:25 |
| thomi | robert_ancell: ^ | 22:26 |
| thomi | thanks robert_ancell | 22:26 |
| thomi | err robotfuel | 22:26 |
| robert_ancell | thanks robotfuel! | 22:26 |
| robotfuel | thomi: BTW, I had to add apt-get install the intel radeon and nouveau drivers to get the qa ppa2 to work today | 22:27 |
| thomi | does the image install the proprietary drivers by default? | 22:28 |
| robotfuel | no those are the opensource drivers, they were pinned in the ppa, but not installed with apt-get install unity-system-compositor | 22:29 |
| robotfuel | if I explicitly do apt-get install xserver-xorg-<driver> they did get installed from the ppa | 22:29 |
| robotfuel | thomi: robert_ancell: BTW benchmarks are live http://reports.qa.ubuntu.com/graphics/openarena/ | 22:31 |
| robert_ancell | robotfuel, this is from the main archive? | 22:31 |
| thomi | robotfuel: cool, I see my graph suggestions were too contentous to apply at short notice ;) | 22:32 |
| robotfuel | robert_ancell: yes the main archive | 22:32 |
| robert_ancell | robotfuel, can we get a line graph or similar? It's hard to tell if they're changing over time | 22:32 |
| robotfuel | thomi: I had your suggestions done in my first revision of the benchmarks using google charts. with the line graph and one day of results. | 22:32 |
| robotfuel | thomi: they didn't like the line graph | 22:33 |
| robotfuel | :( | 22:33 |
| thomi | yeah well, there's no educating some people | 22:33 |
| robotfuel | thomi: I could make a http://reports.qa.ubuntu.com/graphics/openarena/line and display a line graph | 22:34 |
| thomi | I should send someone a high school textbook and highlight the sections about histograms and bar graphs | 22:34 |
| thomi | robotfuel: nah, it's cool, I don't care that much :) | 22:34 |
| robotfuel | ok :) I am EOD ttyl | 22:34 |
| RAOF | Alright. Let's see if I can track down what madness I unleashed on radeon... | 22:35 |
| bschaefer | RAOF, if you need something to test out you can send me a patch :) | 22:38 |
| jono | RAOF, is https://bugs.launchpad.net/xmir/+bug/1192843 fixed? | 22:38 |
| ubot5 | Launchpad bug 1192843 in XMir "XMir receives input from other VTs" [Critical,In progress] | 22:38 |
| RAOF | jono: no | 22:38 |
| jono | Matthew Garrett raised a valid point about this | 22:38 |
| jono | and I don't a clear mention of a security issue on the call for testing | 22:38 |
| jono | kgunn, ^ | 22:39 |
| RAOF | Yes, we should stick a big fat warning on that. | 22:40 |
| kgunn | RAOF: jono robert_ancell ....i thot this was fixed | 22:40 |
| kgunn | we landed and i thot robert_ancell rebased on | 22:41 |
| RAOF | kgunn: The mir infrastructure required to fix that in XMir has landed; the actual fix in XMir isn't implemented. | 22:41 |
| robert_ancell | kgunn, no, only the first part of the fix is done - the bug report mentions that | 22:41 |
| jono | kgunn, RAOF, robert_ancell this really should have been mentioned in the call for testing | 22:41 |
| jono | I am updating the wiki now | 22:41 |
| kgunn | robert_ancell: my bad...can you add that to the ppa preamble ? | 22:41 |
| robert_ancell | kgunn, yes | 22:42 |
| kgunn | jono: so sorry...i really can't believe i missed that | 22:42 |
| kgunn | i guess we'll know if Matthew tries to test | 22:42 |
| jono | kgunn, unfortunately I heard about it from Matthew Garrett on Twitter | 22:42 |
| kgunn | jono: sorry... | 22:42 |
| jono | kgunn, nm | 22:43 |
| robert_ancell | kgunn, updated | 22:44 |
| kgunn | ta | 22:44 |
| robert_ancell | RAOF, anything I can do to help get that fixed in XMir? | 22:44 |
| robert_ancell | kgunn, there's two bugs marked "sessions" at the bottom of the description of the PPA - did you add that? | 22:45 |
| kgunn | robert_ancell: nope those were there... | 22:45 |
| robert_ancell | it's the VT input bugs, I've just moved them to the top | 22:46 |
| RAOF | robert_ancell: You could check that USC marks every surface as unfocused on VT switch. | 22:50 |
| robert_ancell | RAOF, will do | 22:50 |
| RAOF | robert_ancell: And that USC marks (at least one, but preferably) each window of an active session as focused. | 22:51 |
| kgunn | robert_ancell: i'm actually going get off for a while....but i'll be back on late just to check in | 23:06 |
| robert_ancell | kgunn, bye | 23:07 |
| * robert_ancell -> lunch | 23:56 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!