[00:47] Ok. I'm confused. [00:47] racarr: Around? [01:03] RAOF: Yeah [01:08] racarr: Do you have any goddamned idea why https://bugs.launchpad.net/mir/+bug/1204939 might be happening? [01:08] Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged] [01:08] Check out the patch in the description, plus the server & client output. [01:16] System hang [01:17] Except you can ssh into the machine in this state, and attach gdb to whatever you want to, and prod it. [01:17] oh no I meant I had a system hang [01:17] Hah. [01:17] :) [01:17] So you did not get my question? [01:18] I do not have an immediate guess.. [01:18] I ust cancelled all my evening plans though because I am having weirdcramps (kind of overexerting lately) [01:18] so I can look at it some tonight lol [01:18] Um, if I had any god damned idea? [01:18] Boo cramps! [01:20] sok. I think it's from building a massive metal dome hich was pretty satisfying [01:20] ok. I will think about it and be back after dinner ~40 minutes? [01:20] thomi: I have this new bug that prevents nexuiz from running on xmir for benchmarks https://bugs.launchpad.net/xmir/+bug/1212062 [01:21] Launchpad bug 1212062 in XMir "xmir crashes to greeter when running nexuiz phoronix test" [Undecided,New] [01:21] thomi: logs aren't that good at pin pointing the crash :/ [01:21] Heh. Pulseaudio appears to think that my HDMI audio sink is at 48KHz whereas it's really 44.1KHz. Dummy sounds really weird sped up by 10% :) [01:22] robotfuel: Wait, apport didn't catch the actual segfault? [01:22] RAOF: no the logs are pretty much not useful [01:25] RAOF: the u-s-c log shows it's restarting, but that's it. [01:27] Bah. [01:28] Apport *should* catch that segfault and give us a lovely symbolic backtrace. [01:31] Whee. Nexuiz is pretty big. [01:36] RAOF: I had it turned off, I've turned it back on and will upload the crash it collects [01:37] a [01:37] Ah, cool. [01:38] I didn't want stray windows about a web apps crashes messing with my benchmark numbers. [01:39] Fair call. [01:45] RAOF: thomi the new bug via apport https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1212065 [01:45] Error: launchpad bug 1212065 not found [01:45] I'll make the other one a dupe [01:46] Ta muchly. [01:46] seems like it's still private [01:46] at least until the LP retracer thingie does it's work [01:46] I should be able to see it even while it's private, but I can't. [01:47] I made it public [01:47] strange that it was private [01:47] bugs with stack traces that might contain private info are marked private by default [01:48] lp then redacts that information and makes the bug public again [01:48] I've moved the bug to xmir because it only happens when the u-s-c is installedhttps://bugs.launchpad.net/xmir/+bug/1212065 [01:48] Launchpad bug 1212065 in XMir "Xorg crashed with SIGABRT in VidModeSetViewPort()" [Undecided,New] [01:49] ugh No symbol table info available. maybe I need dbg packages? [01:49] robotfuel: Nah, the apport retracer should go back in and fill in everything. [01:50] *should* ☺ [01:52] I have to run thanks for your help RAOF and thomi [03:27] RAOF: any luck with that bug? [03:27] thomi: The nexuiz bug? The retracer hasn't touched it yet. [03:28] boooo [03:28] Ah, there we go. [03:28] oh? [03:29] The retracer has now touched it :) [03:31] Huh, yes. That's not going to work. [03:31] :) [03:35] RAOF: I may have gotten distracted when I found the dongle to plug my guitar in to my computer [03:35] racarr: Woot! [03:35] I am back to thinking though um [03:35] so how does the failsafe X session [03:35] RAOF: why not? [03:35] come in to play? [03:36] racarr: The failsafe X session doesn't come into play. Or, rather, it comes into play after the test times out and decides that it's all gone pear-shaped. [03:36] oh ok [03:36] thomi: Because it calls sna_crtc_set_mode_major; we need to disable that codepath under nested :) [03:36] racarr: I need to set up my keyboard somewhere that I can actually play it. Also, find all my music. ☺ [03:37] RAOF: ok, so "That's not going to work" means "I know what the problem is, and how to fix it", not (as I thought) "the new stack trace does not help me fix the issue" :) [03:37] thomi: Right. [03:37] RAOF: racarr: in Boston, we should get instruments and have a mir-team plus guests jam session :) [03:38] Oh...yes we should! [03:38] I'll bring my guitar [03:38] thomi: I'd be pretty rubbish at a jam session, I suspect :) [03:38] no way I'm taking my guitar on an American airline flight though :) [03:38] RAOF: me too, that's half the fun :) [03:38] RAOF: Chords! [03:38] then you add notes, and add fewer if they sound really bad [03:38] it's easy [03:38] :) [03:39] Ok so wait this lastlog [03:39] seems to imply that [03:39] http://www.homestarrunner.com/sbemail36.html [03:39] drmAuthMagic [03:39] oh wait [03:40] ok so is that actually failing? andit's a permissions sorta thing with the session stuff [03:40] or could it still be [03:40] some sort of mir failing to send the reply [03:40] Yeah, that's what I thought. [03:41] Because you can see the second request successfully written to the socket, but nothing server-side about it. [03:42] RAOF: any idea when we can land the X fix? I need to give an estimate to olli [03:42] thomi: For nexuiz? [03:42] thomi: I'll fix it up now if it's urgent. [03:42] Clearly it is urgent, so… [03:43] RAOF: ButI mean around [03:43] http://paste.ubuntu.com/5983202/ [03:43] l155, do we know if ret < 0?Or is it still unclear [03:43] RAOF: yeah, I'd say it's pretty urgent, it's blocking xmir certainly [03:43] thomi: Along with this ati banana, yeah. [03:44] :) [03:44] racarr: We don't know if ret < 0, but we do know that we never get there the second time. Also, we know that the first call succeeds. [03:44] (Because otherwise X would be all bailing) [03:45] ohhh [03:45] Also, the exception would propagate out, kill unity-system-compositor, and get logged. [03:45] ok thanks I misinterpreted [03:46] Wait what do you mean we dont get there the second time,Doneauth appearstwice [03:46] Oh I see [03:46] its printed twice [03:48] Right. [03:48] I shouldn't have used the same string for both bits :) [03:48] But you get two entry prints, and the "Done auth" is done for each entry print. [03:49] Man, that's an unclear sentence :) [03:49] Mm [03:50] it would be useful to have [03:50] But for a successful auth you'll see ‘In drm_auth_magic to auth magic:… In DRMHelper::auth_magic… Done auth… Done auth” [03:50] MIR_SERVER_SESSION_MEDIATOR_REPORT and MIR_SERVER_MSG_PROCESSOR_REPORT=log [03:50] I can't figure out, how far the second auth is getting beyond sent [03:51] Ah, right. I've not instrumented the server end of the RPC channel. === chihchun_afk is now known as chihchun [05:33] didrocks: Good morning! [05:33] hey RAOF! thanks for the bug report update [05:33] Thanks for running the tests. [05:33] just a little bit scared about the "I have no idea why" :) [05:33] yw! I got lucky, first time and strike! :) [05:33] :) [05:34] It's even annoying, I was preparing myself to a lot of try & retry pain :) [05:34] RAOF: the machines are free for the next 25 minutes, not sure if this can help though [05:36] Hm. We could try again with MIR_SERVER_SESSION_MEDIATOR_REPORT and MIR_SERVER_MSG_PROCESSOR_REPORT set to log. [05:36] That's what racarr suggested. [05:37] so, environment variable? [05:37] shold we just set them to something like 1? [05:37] Yeah. Or we could pass those options in. [05:37] Nah, both should be set to "log" [05:37] ah ok :) [05:38] let's try that [05:38] Want me to log in, or will you do the honours? [05:38] RAOF: please log in [05:38] I need to refind the run first [05:39] now the question is… what archive was it :p [05:40] :) [05:41] You have the unity launcher always visible? :P [05:41] RAOF: since the update, I can't reveal it anymore [05:41] so forced to have it always visible :/ [05:41] Oh, which update? [05:41] like a month ago [05:41] Huh. Works here. Of course. [05:41] when changing with the latest X the barrier logic [05:42] RAOF: ah, better, it's fixed now \o/ [05:42] a little bit hard, but good enough :) [05:42] Now we have a full 1920px worth of terminal! [05:44] heh, indeed :) [05:44] ok, let me find again the command I wrote to restore an archive :p [05:44] interesting [05:44] who wrote that buggy code? :p [05:46] :) [05:46] RAOF: looks good to you? [05:47] Yup [05:47] RAOF: let's poweroff to have new fresh logs [05:47] Yeah. [05:48] Also, I'm not sure if lightdm does the right thing wrt unity-system-compositor on restart. [05:48] RAOF: do you think we should reboot the machine? [05:48] can do quickly [05:48] I don't think so. [05:48] RAOF: just doing it, as the state was screwed the second time we start it [05:48] Fair 'nuff. [05:48] don't want to pollute the result :) [05:50] ping mlankhorst [05:50] RAOF: please re-ssh and re-byobu :) [05:51] RAOF: it's all yours now [05:52] didrocks: Bah, that worked. [05:52] argh indeed [05:52] let's try to shut it down [05:52] Although I don't see the logs I'd expect. [05:52] and reboot again [05:52] ah? [05:52] So maybe the environment isn't set in the right place? [05:52] hum [05:52] didn't I write in that file? :/ [05:53] We could also edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor [05:53] let's retry first [05:53] Yeah [05:54] RAOF: quick way to see it worked or not? [05:54] RAOF: if not, you can poweroff/restart [05:54] Didn't get the logs we wanted. [05:54] Also, worked. [05:55] ok, I let you edit :) [05:55] (annoying those apps changing term cap) [05:57] didrocks: Going to shut down and try again? [05:57] RAOF: please do :) [05:58] I've not paid attention as to how you actually start it ;) [05:58] Although I guess the key could work :) [05:58] ah ok :) [05:58] yeah [05:58] RAOF: waow, how did you guess the default user password? :p [05:58] * didrocks runs… [05:58] :) [05:59] ok, restarted then [06:01] RAOF: no luck? [06:02] Wah, box keeps being restarted. [06:02] oh right [06:02] let me fix that [06:02] sorry [06:04] urgh [06:04] that's weird [06:04] it should have copied the "fixed versoin" [06:04] let me recheck [06:04] RAOF: in fact all the tests ran [06:04] that's why it's shutting down [06:05] grrr, this starts to be annoying, last time it was the way to go [06:07] oh [06:07] I'm sooooo stupid [06:07] saucy-i386-20130813-0917 [06:07] saucy-i386-20130809-0917 [06:07] in the path [06:08] I could have tried for a long time… [06:08] :) [06:08] ok, this time, my first attempt should be the right one [06:08] that explains as well why the /etc/environment wasn't exposed [06:08] Heh [06:09] ok good :) [06:09] shoudln't restart now [06:09] the stage is yours [06:10] Great. So, we've got the logs we're after. [06:10] \o/ [06:10] Now we just need to actually trigger the bug. [06:10] right [06:11] * RAOF is on Mir weekly call for a while [06:11] ok ;) [06:12] Feel free to keep restarting until you hit the bug :) [06:13] RAOF: doing :p [06:17] bah… 15 restarts without any issue, I wonder if the debugging log helped maybe to slow it down enough [06:18] Yay heisenbug? [06:20] exactly :/ [06:21] RAOF: yeah, I have no idea :/ [06:25] RAOF: I've archived it just in case [06:26] TA. [06:27] should I give back the machine to production? [06:28] (I guess still ~5 minutes for it being free) [06:29] yeah, the machine is needed, freeing it [06:37] Sorry, yeah. [07:10] good morning [07:10] racarr / ricmm: re: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/revision/165 (mir backends) - there's double dh_auto_configure, the latter one under override_dh_install. that's probably harmless, but also unintentional? [07:27] Mirv: I think that was me, and it was unintentional [07:40] racarr: ok, filed bug #1212131 [07:40] bug 1212131 in qtubuntu "Double dh_auto_configure in debian/rules" [Undecided,New] https://launchpad.net/bugs/1212131 [07:41] I'm just finishing testing with the new packages, just to be sure [07:43] works fine on nexus 4 [07:43] (which was to be expected, but I just wanted to see it in action..) [07:45] duflu: pong [07:45] mlankhorst: Sorry in hangout now [07:51] duflu: hi! Once you're over with the hangout, I know you're busy but you might have some quick insights on https://bugs.launchpad.net/mir/+bug/1204939 with the new debugging data, as per Didiers comment: [07:51] Launchpad bug 1204939 in Mir "Unity doesn't start on ATI test machine (Mir fails to respond to drm_auth_magic request)" [Critical,Triaged] [07:51] https://bugs.launchpad.net/mir/+bug/1204939/comments/11 [07:52] Since we had to block releases of the mir stacks because of that [07:56] Mirv: I'm glad you expected it ;) [08:17] sil2100: We were just discussing that in the hangout. People generally agree that we have not yet ruled out some socket needs better flushing, or similar. RAOF was working on it but just went to dinner I think [08:18] It's just a theory. We're at least getting closer to where the cause might be [08:19] mlankhorst: I'm getting: bo ffff880082c01000 pinned elsewhere: 0x00000002 vs 0x00000004 [08:19] ... which sounds like my bo is pinned to "TT" when I'm trying to pin it to VRAM. But I don't understand what it really means by "TT" === dholbach_ is now known as dholbach [08:20] TT is translation table, eg gart :P [08:20] are you on a 3.11 kernel? [08:20] mlankhorst: Oh. No this is 3.8 (raring) [08:21] mlankhorst: RAOF said it sounded like something you fixed recently... ? [08:21] Though I am definitely open to blaming my own code still [08:22] * duflu grabs a newer kernel [08:24] tvoss: I didn't actually mean it when I said I was going to sleep. That's many hours away :) [08:25] a framebuffer will be in VRAM, exporting a handle as dma-buf will pin it to GART [08:25] tvoss_^ [08:25] on older kernels, 3.11 fixed this [08:25] mlankhorst: Cool thanks. I will give 3.11 a spin [08:26] duflu: thanks guys :) [08:28] brb [08:32] alan_g: How confident are you that none of our sockets will ever need more flushing than we do already? It sounds like sil2100's issues could be caused by a socket buffering a request or response, but never accumulating enough to flush... [08:33] duflu: it isn't something I've thought about. [08:33] Fair enough. So it's not impossible I guess [08:41] duflu: alan_g: It's unlikely that socket buffering would actually cause data not to be sent at all. In the worst case it would introduce a small delay while waiting for other data to come along. [08:42] alf__: Worth thinking about for performance at least I guess [08:50] ping greyback [08:51] duflu: pong [08:51] greyback: Can you confirm the fix for bug 1199450? [08:51] bug 1199450 in Mir "[xmir] Inputs slowing, last event of a stream of events greatly delayed" [Critical,Fix released] https://launchpad.net/bugs/1199450 [08:52] duflu: can do. Let me reboot [08:52] Ta [08:53] * duflu has managed to simulate the bug with demo_client_fingerpaint but never see it in the wild === seb128_ is now known as seb128 [10:01] greyback: Any good news before I depart? [10:02] duflu: so far, inputs are immediate, so I think bug is fixed. As it used to take several hours for bug to be noticeable, I'll work the day before marking bug as fixed [10:02] greyback: OK, thanks for testing that [10:03] duflu: thanks for fixing :) [10:03] greyback: No problem. It was consequential to other work I was already doing. BTW using Intel GPUs? [10:04] duflu: yep, sandybridge [10:04] Cool [10:12] mlankhorst: nouveau seems to be (successfully) doing multiple page flips per vblank... [10:12] Or am I imagining things? [10:13] unfortunately not.. [10:14] I have 2 patches that help with the vblanking some [10:15] sec [10:15] http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=4d2b97bdaebd7686075bce5ad1a498918d2ab17f^ [10:15] http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=4d2b97bdaebd7686075bce5ad1a498918d2ab17f [10:17] mlankhorst, OK awesome to see you're already onto it [10:17] I may have to enter kernel land and test those tomorrow... [10:17] duflu: well the fix is really from the second commit in nouveau_display.c -- you should try that separately :P [10:18] but I'm still getting > 60 fps with compositing somehow, dno why [10:30] ah now I understand === alan_g is now known as alan_g|tea [10:41] nouveau ddx is messy :/ === alan_g|tea is now known as alan_g === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g [13:04] Hmm with the new fangled mir_connection_create_display_config() interface, how do we determine the size of the display? Is MirDisplayMode::vertical_resolution the height? === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:55] didrocks, I checked with RAOF yday on the ATI bug [15:56] discussing whether the stop is warranted or not [15:56] olli_: ah nice! we discussed a little bit/tried to debug together this morning [15:57] (no success though) [15:57] he said we should block mostly to "help" you [15:58] i.e. it is probably not an ATI spec. problem but a sporadic IPC one but if we don't get it fixed you will just reboot your system over and over again [15:58] didrocks, just wanted to share that with you [15:58] to show some sympathy ;) [15:59] olli_: yeah, or have to skip this tests on that machine and add an hack for this one… [15:59] olli_: thanks ;) let's see how it goes on a longer term [15:59] racarr: ping when you're online === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [16:26] didrocks, what is wrong with this line in debian/control? [16:26] -- Thomas Voss (thomas.voss@canonical.com) Mon, 12 Aug 2013 15:51:35 [16:27] tvoss_: you shouldn't have this line in debian/control [16:27] or you meant debian/changelog? [16:27] didrocks, changelog, sorry :) [16:27] ah, spotted it :) [16:27] tvoss_: you need a double space and < > between your email address [16:27] so: [16:28] -- Thomas Voss Mon, 12 Aug 2013 15:51:35 [16:28] not sure what you try to do to have () and only one space ;) [16:29] didrocks, still no luck [16:29] -- Thomas Voss Mon, 12 Aug 2013 15:51:35 [16:30] tvoss_: you don't have the timezone [16:30] -- Thomas Voss Mon, 12 Aug 2013 15:51:35 +0200 [16:30] not sure why you try by hand instead of dch -i, really ;) === alan_g is now known as alan_g|EOD [18:22] small branch, memory leak in multi win demo: https://code.launchpad.net/~brandontschaefer/mir/fix-memory-leak-mutli-win-example/+merge/180210 [18:23] and small memory leak, just 3 surfaces ~4k bytes [19:41] These lateoclock meetings just do not ork ell for me [19:41] I got so woken up I couldnt get to sleep until 4 [19:55] racarr: there? [19:56] tsdgeos: Yes :) sorry [19:56] racarr: did you get the nexus4 mir thing to work? [19:56] I went to our lateoclock meeting last night...and wasn't able to get to sleep afterwards [19:56] Yes! but then I realized I was testing unity8 with old packages still because path wasn't thought I was [19:57] and the PPA isn't installable at the moment [19:57] so now I am building qtubuntu, etc [19:57] just mir trunk, all the demos, etc [19:57] so I guess, I will hopefully see the problem soon at least [19:58] racarr: well, my problem is, i can't even get anything on screen with mir_demo_client_accelerated [19:58] racarr: is all the stuff you use from packages? or you use some code yet to be commited? [19:58] tsdgeos: Ah see, I just did a clean build [19:58] of mir trunk and the demo clients work fine [19:59] I think I didn't try demo_client_accelerated in particular, but did try demo_render_surfaces, demo_render_to_fb, demo_fingerpaint, and demo_inprocess_egl [19:59] well i'm using the image [19:59] hmm [20:00] any idea why i may not be getting anything? [20:04] tsdgeos: We are sure surface flinger is dead? [20:04] racarr: well, it's not showing in ps, is that enough? [20:06] I think actually it might not show up in normal PS anyway because it's on the other side of the LXC container [20:06] but I'm not 100% sure [20:06] with no surface flinger [20:06] nexus 4 should get stuck on the [20:06] "Google" screen [20:06] probably [20:06] tsdgeos: There may be something useful if you run the server with [20:06] MIR_SERVER_DISPLAY_REPORT=log [20:07] yes, it gets stuck on the google screen [20:07] did you try the standalone mir demos? [20:07] render_surfaces, render_to_fb and inprocess_egl? [20:07] racarr: which binary is that? [20:07] is that in any deb pkg? [20:07] or do i have to compile mir? [20:08] tsdgeos: sorry I keep on thinking you have a build directory XD [20:08] um [20:08] I think they were in the demos packagge at least [20:08] mir_demo_standalone_* [20:08] racarr: shall i run as root, as phablet or don't care? [20:08] inprocess_egl, render_surfaces, render_to_fb [20:09] um, you know I had success running them as phablet but I didn't think that was supposed to work [20:09] so lets go with root XD [20:09] and MIR_SERVER_DISPLAY_REPORT=log if they don't work [20:09] racarr: you get the shell on your n4 ? [20:10] racarr: so this is the server output http://paste.ubuntu.com/5986351/ [20:11] and this is the client [20:11] http://paste.ubuntu.com/5986353/ [20:11] still nothing on screen [20:13] tsdgeos: When you run the standalone ones [20:13] run without a server [20:13] ricmm: I was running old packages XD [20:13] racarr: the only standalone i can find is mir_demo_standalone_input_filter [20:14] Really ok I guess we don't build them anymore [20:14] and well, that does output stuff to the shell [20:14] but i don't see anything [20:14] not sure if i should be seeing anything or not [20:14] racarr: so now it doesnt work? [20:14] not with input_filter [20:14] racarr: i guess i can try building stuff if that helps [20:14] ricmm: Well I am still building to verify, it seems not too though [20:14] tsdgeos: Yes, I think that ould be the next step if you can [20:14] just start with building mir [20:14] and we can run the integration-tests binary [20:15] which will verify a lot of [20:15] driver stuff [20:15] but i'm confused as of why you see stuff when using the image and you don't [20:15]