[00:05] RAOF: anything noteworthy about xserver mm 14 & intel mm7 ? [00:06] 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:07] ah,....i see buffer stride via the interface [00:09] Yeah. [00:10] You know what would be awesome? If our acceptance tests weren't riddled with non-deterministic failures :( [00:10] thomi, ah, xrandr is considered a bit unstable [00:11] ugh [00:18] thomi: Also, that check will become incorrect as soon as I create outputs with correct names (like HDMI-1 and eDP-1, etc) [00:19] so, what should it be doind? [00:19] *doing [00:21] ‘grep "LoadModule.*xmir" /var/log/Xorg.${DISPLAY#:}.log’ is reasonable. [00:23] RAOF: thanks [00:23] robert_ancell: that fix is now in place - should I run the tests again? [00:23] thomi, please do [00:24] robert_ancell: it seems like some jobs are already running :-/ [00:24] thomi, I started it earlier, some might not have completed [00:24] should I kill them, or wait? [00:25] thomi, kill them [00:26] ok, they're running again [01:16] * RAOF wonders whether he should set up an android test environment or just wait the 30minutes for Jenkins to run the tests... [01:36] 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:40] I'd just like a script that I didn't have to Ctrl+C part way through to use effectively [01:41] Though, I also don't have an N4 right now :/ [01:44] Are we waiting on anything to get the bypass patch back in the PPA for testing? [01:45] robert_ancell, RAOF ^ [01:52] We should probably reverse copy from qa-testing2 to qu-testing now that MM is pretty much good in qa-testing2 [02:01] RAOF: Did you try ignoring buffer age yet? [02:02] duflu: Yes. I was just about to say that it doesn't help. [02:02] :) [02:02] Fark. Well at least we know it's not from bypass. Back to square one [02:03] It's going to be the compositor displaying buffers out of order again. [02:04] 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:05] lp:mir is still /too flawless/. There's something our demos are not doing to trigger the bug [02:06] RAOF: Can you please triple check going age-less? I don't want to spent more days in that rabbit hole accidentally... [02:07] Ok [02:10] 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:13] RAOF: That's feasible [02:14] Though we are almost certain already that it's the wrong order. The how and why is important [02:14] And how to reproduce it with lp:mir servers/clients only [02:30] duflu, last I heard from kgunn and olli, yes [02:31] duflu, sorry, "back into the PPA" - do you mean the multi-monitor PPA? [02:35] * 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:36] robert_ancell: Yes qa-testing*. If there are any bugs then someone needs to tell me [02:38] duflu, at the moment we just want to be sure mm works before combining it with bypass [02:40] robert_ancell: No problem. I only feared that some miscommunication about it being hideously broken may have occurred [02:41] duflu, does using bypass together amplify some bug still? [02:41] 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:44] 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:45] RAOF: Ok, ta [02:46] Huh. It's actually *two* frames behind! [02:47] * RAOF types 123 into an xterm, and sees ‘1’ [02:49] Hmm, I wonder what Mir clients look like when the bug is occurring [02:50] Probably roughly normal, because they almost all buffer swap at vsync? [02:50] Only fingerpaint is likely to show anything, right? [02:51] RAOF: Probably, but does it get input? I'll try [02:51] Oh no, I can't the output_id fix isn't in the PPA yet [02:52] RAOF: I'm not sure now. Is it only lag or wrong order too? [02:53] On the second head it seems to be purely lag. [02:53] RAOF: Hmm, hold a key down and sometimes you do see the future for a split second. That's wrong order [02:53] Ah, yes. [02:53] There we go. [02:54] Should we say seeing the future is a *feature*? [02:54] Lag *and* out of order :) [02:54] Interestingly, one monitor is bug-free [02:54] Yeah. We fixed the "only one surface buffer order presentation" problem :/ [02:55] OK, I have some good hints to work with [02:56] RAOF: Have you seen any order problems with just one output? [02:57] No [02:59] * RAOF luncheons [03:05] 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:06] i'll defer to you guys what order things need to land... [03:06] kgunn, duflu, I vote we land bypass now [03:08] 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] 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:09] robert_ancell: so...wrt multimon ppa....we just make sure not to let mir get rebuilt once its in archive ? [03:09] kgunn, we can make an inverse bypass branch if necessary for now [03:10] robert_ancell: Do we need an env var to control it in case? [03:10] duflu, I wasn't aware it could be switched off - there may be a case for an option to disable it then [03:10] duflu: i personally like that idea...we had one in android & used it often for debug [03:11] OK, will hack the option into the bypass branch first [03:11] if its low investment of ur time [03:11] It's trivial [03:13] cool [03:14] kgunn, thomi, do you have the numbers for the bypass test? [03:16] robert_ancell: thomi ...http://10.97.2.12:8080/view/qa-ppa/ [03:16] so you kinda have to dig a little [03:16] nothing looks completely amiss [03:17] kgunn, yeah, wondering if there's anything to copy and paste into the MP [03:19] brb [03:23] kgunn, robert_ancell: OK you can disable it with MIR_BYPASS=0 [03:24] duflu, awesome [03:24] duflu, did you consider a command line flag? Then it can be disabled by either a flag or an env variable [03:25] robert_ancell: No... would that set the environment internally? If not then there's a lot of wiring up that would require [03:25] duflu, all command line flags can be set with MIR_SERVER_FOO for --foo [03:26] robert_ancell: That doesn't have to be redone for each server right? [03:26] duflu, nope, they all get that [03:28] robert_ancell: so...should we line up the canonical folks tonight we want to give multimon a shot their morning ?? [03:28] kgunn, RAOF, it only works for intel right? [03:28] or should we wait a bit ? [03:28] Now it's a non-trivial exercise :/ [03:29] robert_ancell: i thot you were trying to run it on the boston 8 earlier ?...did ati/nouveau fail ? [03:29] robert_ancell: Too complex to rush in such logic right now. It's pretty hidden so we can change it later [03:30] ... because getting command line option values seems to create complex class dependencies [03:30] 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:34] robert_ancell: re-running with some tweaks to the test script [03:35] robert_ancell: ati & nouveau should work, but I haven't tested them. [03:36] cool...so we could just line up the internal testers w reckless abandon [03:38] Yup. [03:38] thomi: think we could get a sanity (e.g. does it boot) on ati/nouveau within an hour ? [03:39] on the boston 8? [03:39] I can just run them without the test, if you like [03:39] yes...or any for that mattter [03:39] Yes, that would be nice. [03:40] ...do we expect it to not boot!? [03:40] yeah...i just don't want to tell people to test w/o having some idea of what will happen [03:40] Oh, I expect it to boot, but it *might* not bring up X [03:40] :) [03:40] just a little thing like that [03:40] I don't *think* that there's anything wrong with the changes, but I haven't tested them :) [03:40] so yeah..boot to usable ui is the litmus [03:42] heh, would be a lot easier if I was in the lab, but I can kick it off after the current test runs [03:45] 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:47] Output change? [03:47] USC changes output layout when I fire up mir_demo_client_egltriangle. [03:48] Which is expected behaviour; resolution is per-session. [03:49] RAOF: But XMir is still composited and visible. Just frozen when a Mir client is focussed. [03:49] If it's composited and visible, it should keep rendering [04:04] bbiab [04:10] RAOF, so do you have a multi-monitor desktop working at the moment? [04:10] Yes. [04:10] I can't get spanning working in Unity and while playing with it I just end up with a black screen [04:10] qa-testing2 works fine for me. [04:10] Do you have delicious logs? [04:11] what would you like? I've just restarted into a fresh session [04:12] Xorg log, unity-system-compositor log, & lightdm log? [04:12] brb [04:14] bah, jobs still failing [04:20] robert_ancell: Winning? [04:21] RAOF, ok, lets start with what I see. [04:21] robert_ancell: Winning! https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 [04:21] RAOF, 1. Log into Unity without monitor connected, all good [04:21] 2. Connect monitor [04:22] 3. See a pile of flickering, then second monitor shows mirrored display [04:22] 4. BUT, the second display is taller and thinner than my laptop one so the desktop is cropped and extended [04:22] 5. Can't launch any new X apps [04:23] Good so far. I'm not sure why it flickers so much - I think that Mir is doing more modesetting than necessary. [04:23] the X log shows ~1.6 million lines of "_XSERVTransSocketUNIXAccept: accept() failed" [04:23] 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:24] ah [04:24] (Mir is flooding the server with fds until accept() can't open a new fd) [04:24] I have qa-testing pinned, not qa-testing2 [04:24] ok, I'll rinse and repeat [04:25] 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] thomi, ta [04:25] I gotta go lie down though, I'm sick :( [04:25] will be back later maybe [04:29] thomi, get well! [04:29] RAOF, Do you know if SwapIntervalSignalTest works with fix-multi-surface-buffer-tracking? i.e. is alan_g's problem resolved? [04:29] duflu, can you review that too asap if you need to? [04:29] robert_ancell: Yes, it's resolved. [04:29] robert_ancell: (As you can see from the tests all passing ☺) [04:29] robert_ancell: Yeah. I also have a reasonable theory for bad buffer ordering now. But first, lunch, postoffice, coffee [04:31] I'm going out for a couple of hours; I'll get back to testing once I'm back. [04:32] duflu, do you want to delay landing this? [04:37] RAOF, cool, aside from the known lagging issue it works for me! [04:40] robert_ancell, I don't want to delay anything... Just going to lunch [04:41] duflu, I mean, should we wait for you or you don't plan on reviewing [04:44] kgunn, do you have that list of internal testers for multi-monitor? I'm having trouble finding it in my email [04:50] robert_ancell: i do ...i crafted a setup email just now [04:51] ok, cool [04:54] robert_ancell: i'm gonna send...please read, then just followup with expectations on ati/nouveau [04:56] RAOF, ati/nouveau are expected to work, just no-one has tested them right? [04:57] robert_ancell: yeah...that's what he was saying [04:57] kgunn, the Boston 8 tests are all failing again [04:57] :-| [04:57] kgunn, can you see those jenkins logs? [04:58] http://10.97.2.12:8080/view/qa-ppa2/ [04:58] yeah [05:00] i don't get it tho...it says intel is failing but the results look good [05:00] on both resolutions [05:01] kgunn, where are you looking at results? [05:01] 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] then drill into each folder marked for resolution... [05:02] then composite.xml [05:02] i'm gonna head off to bed....see you tomorrow [05:02] later [05:02] tvoss: i'll see you in ~9 hrs w/ olli :) [05:02] kgunn, ack, later [05:18] RAOF, so you think ati works, but you haven't tested it? You have some ati hardware right? [05:23] 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:27] I'm finishing up for the night, any last requests? [05:28] robert_ancell: Relax? [05:28] that would be awesome [05:36] duflu, ping [05:36] tvoss, pong [07:01] Ok. [07:01] Let's test that radeon boots, at least. [07:04] Argh. I _still_ can't find a theoretical reason for bad frame ordering. The algorithm's designed to make it (theoretically) impossible [07:05] good morning [07:07] Good morning. [07:07] Ah. I seem to have managed to break radeon. Excellent. [07:07] hey RAOF [07:09] perfect [07:09] duflu: maybe it's not the theory, it's the implementation? :P [07:10] mlankhorst: Yeah, which is why I'm trying to find bugs still [07:10] RAOF: perfect, can I look at it? :P [07:11] mlankhorst: You're welcome to. It's... oh, not hosted in any public git tree. [07:11] Let me fix that :) [07:11] I've probably set the stride of the thingy wrong. [07:12] yeah those thingies can get picky [07:18] mlankhorst: github.com/RAOF/xf86-video-ati, branch "foo" [07:18] RAOF: what mir branch etc do I need for that? or ppa [07:19] You need ppa:mir-team/qa-testing2 [07:19] Or github.com/RAOF/xserver , branch vladmir-upstreaming [07:20] ah [07:27] mlankhorst: I'll have set devKind incorrectly in the ModifyPixmapHeader call. [07:27] Becasue I'm still not entirely sure what WTH that's meant to be :) [07:28] mlankhorst: Oh, I may have done the same for nouveau... === kode54 is now known as ]k[ [07:34] mlankhorst: Do you remember offhand what devKind is meant to be for radeon? [07:35] Hm. It *is* meant to be stride. [07:49] RAOF: it's stride for all ddx iirc [07:49] Then I broke it somewhere else :/ [07:49] yeah I'll take a look [07:49] power just cut out :/ [07:50] for like 5 minutes or so [07:52] mlankhorst, in your place? === ]k[ is now known as kode54 [07:56] yeah [08:12] RAOF: do you get something like this? [08:12] [ 403.880155] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9 [08:12] [ 403.880435] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [08:12] Sigh. We may yet need a universal frame counter to throttle clients accurately under multimonitor [08:13] Wait a minute... what is "accurate"? [08:13] Surely if your client doesn't do "accurate" timing and relies on vsync then 120Hz with two monitors is not necessarily wrong :/ [08:13] Hmm [08:15] duflu: that is assuming both monitors have the same scanrate [08:15] mlankhorst: I mean generally sum of all [08:16] I think we've been trying to meet a requirement that doesn't really exist... [08:16] RAOF: lol [08:16] [ 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:19] combined with the previous errors it looks like your handles are corrupted :P [08:22] + if (!pScreen->ModifyPixmapHeader(dst, [08:22] -+ pScrn->virtualX, pScrn->virtualY, [08:22] ++ output_box->x2 - output_box->x1, [08:22] ++ output_box->y2 - output_box->y1, [08:22] looks wrong.. [08:29] hm and the last error might be from freeing a buffer [08:33] hello :) could someone review this branch: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 if not busy? [08:34] RAOF: with valgrind I seem to get more errors :P [08:35] definitely looks like the bo's get unreffed before being used.. [08:37] mlankhorst: That seems... wat? The changes shouldn't change when the bos get unreffed! [08:42] RAOF: well from the dmesg I'm guessing that somewhere something gets freed before it should [08:44] if i run things with valgrind I end up with Xorg failing in random random crashes [08:44] s/random.*/random places/ [08:48] mlankhorst: Oh, that reminds me. I should push the xf86-video-intel change to actually enable the valgrind support. [08:49] wasn't --enable-valgrind already added, or did you redisable it? [08:50] No, it's enabled, but only if DEB_HOST_ARCH == linux [08:50] But DEB_HOST_ARCH is never linux; you misspelt DEB_HOST_ARCH_OS [08:51] oops [08:55] 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] Colour me confused, then. [08:55] erm I mean you're probably freeing something twice [08:55] or before using it [09:02] or a particularly nasty kernel corruption.. I'll try on my older card [09:04] RAOF: were you getting the same kind of errors? [09:07] mlankhorst: Hm, no. [09:09] 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] I'm getting tons of crap like this [09:09] [ 99.170371] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2! [09:09] [ 99.178895] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9 [09:09] and [09:09] [ 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:10] [ 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] Ah, yes. I see those. [09:10] which makes me think that some stuff gets freed by the driver before submitting the commands [09:11] Ah, fair enough. [09:11] * RAOF was confused about your valgrind comment. [09:12] RAOF: well I get some memcpy crashes from valgrind [09:12] but nothing pointing towards what is going on [09:13] Huh, really? [09:13] memcpy? [09:14] RAOF: does the root window have damage tracking after a resize event? [09:14] Yes. [09:14] But we should be disabling everything that has damage associated with the screen pixmap before resizing. [09:15] 'cause we throw away the screen pixmap on resize, but not the root window. [09:15] .. do you? :p [09:18] I'm reasonably sure? [09:18] hm good enough [09:18] Anyway, resize isn't called in xserver startup? [09:19] I'm trying to figure out what is going on there though [09:21] What's your memcpy crash, anyway? [09:26] Woo! Perfect multimonitor frame sync with no timers! [09:29] RAOF: never the same twice :/ [09:29] but usually exa related [09:30] actually always the same it seems, it's from fallback call. same thing that happens when acceleration in nouveau fails [09:30] and preceded by failed to map pixmap: -2 [09:31] hm from procRenderCreateCursor.. [09:33] http://paste.debian.net/30292/ with memory summary removed [09:35] RAOF: it worked on intel right? [09:35] Yeah, works on intel. [09:35] RAOF: implement shadowfb call :P [09:35] Well, actually, my sync is temporarily lost when VT switching, but it comes back eventually [09:35] Also, I *don't* see that CreateCursor crash. [09:36] hm actually it wouldn't help [09:36] it's falling back to downloading to screen because the mapping was failing [09:37] You know, it's rather hard to create visual glitches when you're triple buffering. I never realized just how hard... [09:44] it's easy if you relax the restriction and allow them to be fatal :P [09:48] Heh [09:58] RAOF: also curious it looks like xmir_copy_to_mir was wrong in another place [09:59] Oh? [09:59] you set dst x / y to 0 0, should probably be the same as src x y [10:00] dst x/y is not location in the destination buffer? [10:00] it is [10:00] Then why wouldn't I want it to be 0 0? [10:00] but I'm guessing the destination buffer is full sized? [10:00] No, the destination buffer is output-sized. [10:00] Welcome to the poor-man's Shatter. [10:01] ah.. [10:01] RAOF: you allocate a single bo for the entire screen, but each output uses a chunk of it? [10:02] There's a single bo for the ScreenPixmap. [10:02] But we copy each region that corresponds to an output into a different xmir_window [10:03] nasty [10:03] 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:04] Eh, I don't think it's particularly nastier than having a single framebuffer surface and copying the whole root window into it. [10:09] I don't really see where this particular error is coming from, what is your failure mode? [10:10] Of *course* I don't see this crash under gdb & mir_demo_server_shell! [10:10] BAH. [10:11] ..? [10:13] 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:14] mlankhorst: I can, apparently, quite happily run radeon under mir_demo_server_shell in gdb. [10:15] No crashes, no madness... [10:15] To be fair I'm not *actually* looking at the display; it's upstairs, so it might be entirely wrong ☺ [10:15] RAOF, rofl [10:17] you're like those tv commercials where they put 'not showing the actual product' in small letters on the bottom [10:22] RAOF: is it just the xserver, or a full session? [10:22] Just the X server. [10:22] well duh :P [10:22] Why duh? [10:22] see if it survives this: DISPLAY=:0 XDESKTOP_SESSION=ubuntu /etc/X11/Xsession [10:23] erm [10:23] DESKTOP_SESSION* [10:23] Hm. dmesg does not survive DISPLAY=:33 glxgears :) [10:23] hah [10:23] [ 1806.614838] [drm:r600_cs_common_vline_parse] *ERROR* cannot find crtc 1436857232 [10:24] I'm not surprised it can't find it! [10:24] or are you? DUN DUN DUUUN [10:24] 55a4b390 [10:31] RAOF: ah right, it's calling evergreen_cp_wait_vline_sync [10:31] That seems unlikely to work. I thought I disabled vsyncing? [10:33] all the calls are hidden behind accel_state->vsync [10:34] okay, time to take care of my visum for china [10:34] Oh, dear. [10:35] No, I undisabled vsynching when I shoved a non-null driver private in xf86Crtc. [10:36] 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:39] mlankhorst: Try bailing early with NULL from radeon_pick_best_crtc (in radeon_video.c)? [10:40] Ok, time for me to sleep [10:53] that's xv stuff.. [10:54] RAOF: did you explicitly enable vsync or something? [10:55] looks like vsync is disabled in radeon unless you explicitly enable it [11:00] hm indeed, same issue here :p [11:02] radeon_dri2.c: info->accel_state->vsync = info->swapBuffersWait; [11:02] - OPTION_SWAPBUFFERS_WAIT, TRUE); [11:03] + OPTION_SWAPBUFFERS_WAIT, !xorgMir); [11:04] well that gets rid of 1 source of errors.. === hikiko is now known as hikiko|lunch === hikiko|lunch is now known as hikiko [12:07] meh on the crashing call.. [12:07] (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(src))->bo [12:07] $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] atomic = 0}, priv_ptr = 0x0} [12:07] (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(dst))->bo [12:07] $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] atomic = 0}, priv_ptr = 0x0} [12:07] [ 491.685460] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9 [12:08] it still has refcount set >:( === chihchun is now known as chihchun_afk [12:17] duflu: so is that branch good to go ?....e.g. add it to qa-testing2? or just build local for more confidence? [13:02] mlankhorst: i see chris went to bed, so does ati work with multimon ? (i'm guessing no...) [13:03] kgunn: it sort of looks like I'm hitting a kernel bug [13:04] mlankhorst: does it work on standard xmir (w.o multimon?) [13:05] hm I ws trying to rollback kernel, I guess standard xmir would be easier to test [13:05] mlankhorst: glad i asked :) save you some effort [13:14] hm I guess that works, weird stuff.. [13:17] mlankhorst: so xmir in archive works...but xmir (multimon, qa-testing2 ppa) does not ? [13:18] yeah [13:18] meaning...can't boot to unity ? or cycles endlessly on greeter ?...curious the symptom/end user result [13:18] right now I just forced it to crash, saves times [13:18] :) [13:19] ricmm: i know you're swamped....had a chance to try xmir-multimonitor? [13:19] rsalveti: ^ [13:20] kgunn: will try today, have an ati board here [13:20] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] [13:21] rsalveti: well... :) ...i'm sure you can see mlankhorst 's posts above [13:21] but is that the same board? [13:21] mine is quite old [13:22] but guess I'd get the same crash [13:22] we'll see [13:23] kgunn: negativo [13:23] and I actually cant, I dont have a second monitor [13:23] :( [13:26] not required [13:26] I was testing a single monitor setup [13:27] ricmm: so it would still be useful to see if you can boot into a useable unity session even on 1 monitor [13:53] 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] altho...looks like it hung or bailed on the last test (unsure) [13:54] ....looking from syslog...whoopsie might have gotten in the way ? [13:54] mlankhorst: ^....just sharing...no action [13:54] nouveau is easier to test though :P [13:54] thomi: robotfuel ^ [13:55]