[00:37] robert_ancell: on the reporting stuff...here http://unity.ubuntu.com/mir/component_reports.html [00:37] so lttng obviously needs lttng [00:37] but for handlers "log" [00:38] does that just get written out to a file ? [00:39] kgunn, I think you need to run it with --glog for the logs to go to glog then you can set --glog-stderrthreshold to have them go to stderr or --glog-log-dir to change where the log files go [00:39] I haven't mastered the logging commands yet though [00:40] robert_ancell: yeah...it says you can define an envrion variable [00:40] to turn it on...which i assume means like "export MIR_SERVER_DISPLAY_REPORT=log" [00:41] kgunn, you can set any of the flags to mir by using MIR_SERVER_* environment variables, e.g. MIR_SERVER_GLOG_LOG_DIR=/tmp/logs [00:41] yep, that would be the equivalent of --display-report=log [00:41] robert_ancell: can that be post server launch ?...or will i need to reboot ? [00:42] kgunn, env variables need to be defined before server launch [00:42] kgunn, you can set them in /etc/environment if you want them universally applied [00:42] like in a pref file ? [00:42] oh... [00:43] kgunn, or edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf and set unity-compositor-command as you like if you're testing the whole stack [00:56] robert_ancell: huh...so i tried to alter envirnonment on the nexus4...but no matter what nano just won't write out the change [00:56] ever experienced anything like that on n4 ? [00:56] i root shell... [00:56] oops/i/i am [00:57] write out what change? [00:57] oh, editing the file? [00:57] what does mount say? [00:57] robert_ancell: correct...trying to add GLOG.... & MIR_.... [00:58] robert_ancell: mount says a bunch...so i guess it depends... [00:58] try 'touch /etc/blah' and see if it throws an error [00:58] alot of "rw"'s [01:00] robert_ancell: touch worked...chmod worked.... [01:00] kgunn, nano fail? [01:00] try cat > /etc/... [01:00] :) [01:02] weird...so "cat > /etc/environment" just sat there... [01:02] no output [01:03] but i definitely see the file when i open with nano [01:03] kgunn, that overwrites the file [01:03] and i can ctl-O to write out...but then, it prompts what file name to save under...and it simply won't accept "enter" [01:03] then type the contents and press ctrl+d to end [01:39] robert_ancell: Morning. [01:39] RAOF, hey [01:44] Hrm. Why doesn't that hit the assert() [01:49] RAOF: hope bkfst was good (something unhealthy like eggs and bacon) [01:49] It did include bacon, yes :) [01:49] Pan-baked eggs with bacon and sausage and onion and such. [01:53] yum [02:10] RAOF, so what's the plan? Are there some specific bugs you are working on? [02:11] So, at least one of the bugs is that we're not updating what Intel thinks the front buffer is. [02:11] That's causing at least *some* of the crashes after resolution change. [02:11] RAOF, this is in Mir? [02:11] This is in XMir. [02:12] My plan is to work on XMir + Intel until I can do resolution & layout changes and it doesn't crash. [02:14] ok [03:09] robert_ancell: well...i added MIR_SERVER_GLOG_LOG_DIR=/tmp/logs & MIR_SERVER_DISPLAY_REPORT=log....but nothing showing up in /tmp/ ? [03:09] kgunn, did you do MIR_SERVER_ENABLE_GLOG=1? [03:10] kgunn, rather MIR_SERVER_GLOG=1? [03:10] doh! [03:17] That sounds quite overcomplicated to me [03:17] hmm still no joy [03:18] robert_ancell: actually would it be MIR_SERVER_GLOG_LOG=1 ? [03:19] kgunn, mir_demo_server --help shows it is '--glog', so it should be MIR_SERVER_GLOG [03:19] kgunn, have you tried setting MIR_SERVER_GLOG_MINLOGLEVEL? [03:19] I had the same frustrations using the logging myself [03:20] robert_ancell: actually...that's a good idea...i should get familiar on pc first before phone [03:20] though --help seems to imply minloglevel is set to a valid default [03:20] Hmm, if Mir is logged to unity-system-compositor.log already, why don't we start logging useful stuff by default? [03:22] ... I mean at least "Mir has started successfully and is using these monitors with resolutions... Listening on socket /tmp/mir_socket" [03:24] That would be moderately useful, yes. [03:24] robert_ancell: duflu RAOF ....i think i'm gonna go to bed early...and get up really early...like 4 or 5 am [03:24] kgunn, later [03:24] duflu, that would be super useful [03:25] just not sure when everyone plans to eod...but if it all ends before i get on...can the last man standing write a handoff email....where we're at, what's worthy to test, what the balance of problems is etc. [03:25] kgunn: OK, later [03:27] kgunn, sure [03:31] kgunn: See you later. [03:37] Wow, qa-testing is better now. Just with ugly frame scheduling/damage glitches [03:44] I'm not even sure how it's possible to get the kind of small horizontal line artefacts I see though [03:54] Actually there seem to be some frame scheduling problems in qa-testing2, just much less often [04:05] duflu, have you found anything in the bypass branch that may be causing problems? [04:05] robert_ancell: Nothing bypass-specific yet. All the bugs I've seen happen on qa-testing2 (just take longer) [04:08] robert_ancell: It's extra hard to test things when a recent MM commit broke fingerpaint :/ [04:09] Maybe fingerpaint is to blame. Don't know [05:10] Bah. The xf86 cursor code would really like HW cursor stuff. [05:27] Why does MM look so flawless for demo_server_client? Where are the bugs that XMir triggers?... :( [05:27] *demo_server_shell [05:28] ok, I'm calling it a night - duflu, RAOF, please remember last one here to send out an email update. Thanks! [05:35] RAOF: When you talk about receiving buffer fd's from the server, that's in-protocol, right? Not on the side channel... [05:45] duflu: Correct === tvoss|test is now known as tvoss_ [05:52] duflu, ping [05:52] tvoss_, pong [05:55] RAOF: Sanity check: qa-testing{,2} are different in that "2" has no bypass, right? [05:59] duflu: qa-testing might be a couple of Xserver revisions behind, too. [06:00] I've only been pushing to qa-testing2 [06:01] Except this morning, which is why I tested qa-testing [06:01] Yeah, accidentally :) [06:02] RAOF, are you using swap_buffer_sync or swap_buffer nakedly? [06:02] tvoss_: swap_buffer nakedly. [06:02] interesting, sam reports issues with that [06:05] Oh, really? What issues? [06:06] RAOF: https://bugs.launchpad.net/bugs/1216337 [06:06] Launchpad bug 1216337 in Mir "Client buffers eventually display one frame behind client swap requests" [Undecided,New] [06:06] Ah, that one. [06:07] RAOF: Ooooh, doing native GBM you have a hardware buffer being swapped using the software swap_buffers call I guess. I wonder if we handle that correctly [06:07] Oh, no. A new appearance of the same symptom. [06:07] software swap_buffers call? [06:08] RAOF: Yes mir_surface_swap_buffers* is usually for software only surfaces [06:08] It's also what EGL uses to implement eglSwapBuffers, though. [06:08] It's the only way to get a frame to Mir. [06:09] RAOF: Yeah should be. Just theorizing [06:56] Woot! [06:56] We have a successful layout change with gnome-control-centre [06:57] RAOF: "We" ? :) [06:58] I [06:58] Ok, that's really weird. [06:58] Mir has stuck the surface in the wrong place :) [07:02] tvoss_: Huh. Looks like it was indeed just the software cursor code being hateful. [07:10] OK, my brain is fried and I'm also out of essentials such as... food. So I'm off to the supermarket for a while. [07:10] duflu: Have fun. [07:10] You might be able to test something that works when you return. [07:10] At least on the XMir side. [07:10] And for values of "works" equal to "doesn't crash horribly as soon as you touch the layout" [07:13] RAOF, \o/, uploaded to the ppa, yet? [07:14] xserver MM11 just uploaded. [07:14] RAOF, does that require an updated intel driver? [07:14] Yes, if you want it to work. [07:15] RAOF, ack, I guess mm11 needs to finish compiling first [07:15] * tvoss_ grabs a quick breakfast [07:15] Yup. [07:32] RAOF, the xserver build for i386 hangs on xfvb [07:32] Grr. [07:32] Someone's going to have to work out what's happening there. [07:34] tvoss_: Build retried. [08:32] RAOF, the 64bit build in the ppa hangs again [08:36] quick restart [08:49] RAOF, would it make sense to just disable the xvfb test in the ppa for now? [08:50] Yeah, it probably would. [08:50] RAOF, hitting refresh to check the build is a bit tedious [08:52] RAOF, does mm12 require a new intel driver? [08:53] Nope. [08:53] It just fixes the crash on startup in mm11 that I introduced by testing a subtly different change locally. [08:54] * RAOF prepares to crash his unity-system-compositor by unplugging his HDMI output [08:55] Huh. Didn't crash (yet) [08:56] RAOF: Yeah the Mir server seems to survive hotplugging fine. Even if you don't get to use the new monitors [09:01] mlankhorst: I don't suppose you're seeing the xvfb-run test hang all the goddamned time in the xserver builds you're doing? [09:03] RAOF, just remove it from the ppa version for now [09:04] Yeah, done in mm13 [09:05] RAOF, ack, moving over to the new house, back in a few minutes [09:07] RAOF: Does XMir use buffer age? [09:07] Yes [09:08] I wonder if we're messing that up somehow [09:08] ... in the server [09:10] RAOF: only 50% of the time [09:11] mlankhorst: Yeah :/ [09:21] hey fellas [09:21] RAOF: might fail on virt only though [09:21] kgunn: Good morning. Sleep well? [09:22] mlankhorst: Yeah, maybe. I haven't been tracking that. [09:22] kgunn: Hi. You could sleep more :) [09:22] uh-oh [09:22] Well, until https://launchpad.net/~mir-team/+archive/qa-testing2/+build/4904608 finishes building. [09:22] :) [09:23] time enough to make a coffee [09:24] I have real food I can cook tonight. Wonder if I will get to... [09:25] * RAOF is just eating some real food. [09:25] Oooh, Sam reports similar lag issues and apparently also relies on buffer age [09:38] RAOF: If we get as far is the frame scheduling being the _only_ problem, can you try ignoring buffer age? [09:38] *as far as [09:38] Yes [09:38] (radeon and nouveau already do) [09:38] Or, rather, fail to act on it. [09:39] ... because the only two clients which use buffer age are the only two clients reporting lag/ordering problems [09:39] Heh. [09:39] Huzzah! [09:39] Maybe [09:40] qa-testing2 now has all the things! [09:40] Cool [09:43] cool.... [09:47] Oooh, gnome-control-centre multi-monitor joy without crashes :) [09:48] Yay! [09:48] I shall now do some much-delayed housework in the form of some washing up. [09:50] RAOF, duflu back [09:51] hey tvoss_ [09:51] RAOF: sweet....i just hdmi hotplugged/connect-disconnect 8 times....survived all....just once it didn't scale right [09:52] getting somewhere :) [09:55] kgunn, please try layout changes, too [09:55] via the control center [09:56] It seemed to work, but then bug 1216522 [09:56] bug 1216522 in XMir "XMir hung in xf86CrtcSetModeTransform()" [Critical,New] https://launchpad.net/bugs/1216522 [09:56] woooo-hoooo!!! was just doing that...hdmi extended desktop working & hotplugged [09:57] wooohoo....and dropping the built-in display off works! [09:58] duflu, for https://code.launchpad.net/~vanvugt/mir/distinguish-crtc-exceptions/+merge/181947 [09:58] duflu, are we sure that the type is usable as an array index? cannot tell from the mp [09:59] tvoss_: Yes copied from the header where they are #defined 0 .. 14 [09:59] duflu, ack [09:59] duflu, which header is that? [09:59] want to note it down in my review comment [10:00] tvoss_: It's mentioned in the proposal diff , but /usr/include/xf86drmMode.h [10:01] duflu, top-approved [10:04] tvoss_: RAOF duflu ok...this is really robust...i've not been punted t to the greeter at all....i used hdmi, then i switched to vga, hotplugging all the way, mirror/extended/dropped builtin display....all of works [10:05] even moved the 2nd display virtually [10:05] kgunn: Yeah it's better but I hung X pretty quickly. Meanwhile USC kept running smoothly [10:06] duflu: :( [10:06] duflu: Stop trying to rotate :) [10:07] RAOF: I did no such thing [10:08] RAOF: i tried to rotate actually....didn't work...but x did not crash [10:09] trying reboot scenarios now [10:09] Yeah, I haven't hooked up any of the shadow alloc stuff that's necessary for rotation. [10:09] If I understand it correctly that *shouldn't* be hard. [10:10] RAOF: we can survive CFT w/o that...i'm sure some one somewhere relies on it...but hey..this is prebeta baby [10:10] …having just spent a weekend finding that the goddamned software cursor code dies if you don't dance around it perfectly. [10:12] RAOF: yeah...now i see how folks like you become experts in x...lots..& lots of scar tissue [10:12] OK, I need to get some proper food sorted. Till tomorrow... [10:12] duflu: later [10:12] duflu: Eat well! [10:12] duflu, till tomorrow [10:20] RAOF: tvoss_ nice work guys....this is so robust...i'm gonna upgrade on my primary machine... [10:20] it has display port...so technically one more phys connector type [10:21] was just telling voss....i've only managed to crash x one time....and i'm being pretty damn mean to it [10:22] probably would've crashed in standalone x [10:24] robotfuel: there's no way your on...but if you're gonna do some work on sunday afternoon, qa-testing2 worthy of a run on the anointed 8 or 9 [10:26] As long as they're all intel - patches for nouveau & ati are pending :) [10:26] RAOF: i'm all intel....all the time baby [10:28] RAOF: so was duflu on nouveau (when he managed to "crash his x pretty quickly") [10:28] ...having a hard time seeing crashing it quickly... [10:29] ok...bbiab/rebooting to mm [10:40] kgunn: might depend on graphcis card [10:46] mlankhorst: ack that [10:53] RAOF: tvoss_ ...so this is intersting....i'm on displayport/hdmi...extended desktop, i put my console in 2nd display...i run openarena... [10:54] ...and? [10:54] first i noticed...its totally unhinged...both high & low res going about 100fps [10:55] i'm guessing its cpu or shader limited (obviously not pixels:) [10:55] second thing....it takes me out of extended mode....but correctly changes the settings too....i need to test on standalone X [10:55] maybe this is correct behavior [10:56] Yeah, openarena is going to try and set the mode (if you're running it fullscreen) [10:56] Nice that it works :) [10:57] what was nice...after loading qa-testing2...i had some old display settings (extended & 2nd screen on left hand side instead of right) [10:58] and it just worked! [10:58] i can't wait for ancell to load this into the anointed machines in lexington [10:59] RAOF: why does openarena become unhinged from vsync here ? [11:00] kgunn: Because that's unimplemented; it's always been unhinged from vsync [11:01] RAOF: not so my friend....when i disconnect the cable...i drop back down to ~60fps [11:01] i just did it [11:01] And you're running XMir? [11:01] RAOF: hmmm....could it be in mirror mode... [11:01] Are you sure? [11:02] that the game has 2 buffers to draw into...so for ~every frame in single screen mode...he's counting 2 ? [11:03] RAOF: damn it...rookie...i know for sure it was xmir on the second machine...i just took it for granted on this one... [11:04] RAOF: even tho its X....that's still weird [11:04] unless my theory of 2 fb being available in one frame render is why... [11:05] RAOF: at least i know how X should behave :) [11:05] Hm, don't know :) [11:06] kgunn, details, perhaps we can file a bug about it [11:06] tvoss_: yep..something to chase up with michael [11:06] kgunn, michael? [11:07] ok...rebooting to mm for reals (michael=phoronix) [11:13] RAOF: tvoss_ ...any of you see the return of the lag?... or kind of, its not global... extended desktop irc in one display..terminal in the other [11:13] irc has no lag...but terminal does [11:13] lag=typing letter showing up [11:13] kgunn: Yeah, duflu was also seeing that (as am I) - https://bugs.launchpad.net/bugs/1216337 [11:13] Launchpad bug 1216337 in Mir "Client buffers eventually display one frame behind client swap requests" [Undecided,New] [11:35] kgunn, RAOF duflu had the idea that it might be related to buffer age [11:39] ok...so for sure i'm xmir-mm...re-ran openarena.... [11:39] if i'm extended desktop...it treats the 2 displays like 1 surface (i see some render no one screen and some of the other) [11:40] and it runs at like 25 fps [11:40] if i go to mirror mode....it runs at like 125 fps [11:41] and if i turn off one monitor....the benchmark tries to run, but complains about the video mode and "ends prematurely" [12:00] RAOF: pastebin.canonical.com/96338/....x crash while turning off second display & going between mirror/extended [12:00] EQ overflow (event queue ?) [12:03] actually this is consistent...have hdmi connected, extended desktop, turn off the second display via settings...x crash === rsalveti_ is now known as rsalveti [14:29] kgunn: are you around? did you want me to start a test run on qa ppa2 now? === racarr is now known as racarr|desert [17:56] I am using intel graphics, yet when switching to mir, lightdm crashes and I have to comment out "#type=unity" [17:56] is there any way i can fix that? [22:56] thomi, is there a way to know who started a jenkins job? [22:57] robert_ancell: in the job run page, it says "started by " [22:57] robert_ancell: in the private server anyway, I think that information is stripped on the public instance [22:58] thomi, right, so on http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/1/ where would I see that? [22:58] * thomi looks [22:58] thomi, ah I got it [22:58] yeah, it was started by an upstream job [22:58] because that job was started by the main job I needed to click that [22:58] It was started by Chris [22:58] right, was started by chris [22:59] They all failed, I'm just wondering if I should be worried by that or it was some sort of test run to check the config was working [23:04] kgunn: Hm. Your “EQ overflow” crash is because Mir isn't responding to a message (again ☹) === jono is now known as Guest52668 [23:33] Has anyone tested qa-testing2 against nouveau or radeon? I'm just interested to know if my patches work :) [23:35] RAOF, what's the focus next? ati/nouveu or the lag issue? [23:37] Fixing the client-buffer-tracker MP, then probably lag. I don't have the hardware available to test MM on ati or nouveau. [23:40] RAOF: robert_ancell can run it against the boston 8 [23:41] kgunn, it's running qa-testing2 now [23:41] RAOF:also that EQ overflow only happened once that i caught [23:41] every other time....the xorg log just ends....are post-config [23:41] but no error complaint [23:41] robert_ancell: ack [23:41] fingers crossed [23:42] thomi, it looks like a failure, but I'm not deciphering the build log - http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/2/console [23:42] In my experience the Xorg log just ending tends to be unity-system-compositor dying, and one of the mirclient threads noticing then throwing an exception. [23:42] * thomi looks [23:42] Of course, because it's on a thread it gets logged nowhere. [23:42] "Build step 'Execute shell' marked build as failure" [23:43] 2013-08-25 23:18:32,372 ssh DEBUG: SSH command (/usr/share/utah/client/utah-done.py) failed with return code: 4 [23:43] this might be it [23:43] robert_ancell: right, it looks to me like the actual test failed [23:43] no [23:44] * thomi curses utah [23:44] oh, is it just polling utah - nasty! [23:45] robert_ancell: if you look at how it's configured, it runs: [23:45] run_utah_tests.py -d -m physical --name "$machine" -i "$ISO" -p "$PRESEED_FILE" -l $WORKSPACE master.run || RETCODE=1 [23:45] in the log you can see "RETCODE=1" [23:45] so run_utah failed [23:46] * thomi tries to find out why [23:52] robert_ancell: it's odd - it looks like the tests are running, because I can see FPS results from the openarena run, but something else is failing [23:52] but utah is frustratingly useless - gah [23:59] robert_ancell: the nearest I can make out, the final command in the test script is failing, that is: [23:59] xrandr | grep -i xmir [23:59] which I assume is there to make sure we're running xmir [23:59] so possibly that's the issue here