[00:14] killall mir_stress; [00:14] fun to write ;) [00:19] feel very close to this stress bug [00:19] but need to go help build a dome [00:19] back later :) [00:33] racarr: Yo [00:36] RAOF: Hi! Sorry. I am about to leave (I literally have to go help build a dome) [00:36] That's ok. [00:36] but, I will be around...was hoping we could have a hangout later [00:36] Sure. [00:36] I am jumping more on the xmir train (WHISTLE WHISTLE SCREEEEEECH) [00:36] Wooo wooo! [00:37] and have a few items I want to sync with you on and just in general [00:37] clarify [00:43] Cool. [00:44] Ok play time! === racarr is now known as racarr|themanbur === racarr|themanbur is now known as racarr [00:45] aww truncated [00:45] *runs in shame* [01:05] What the whatting what? My perfectly valid DrawablePtr gets mangled in the process of calling xmir_dri2_drawable_can_bypass. Are there two different definitions of struct _Drawable or something? [01:09] There must be! What the whatting what? [01:22] Well, that's moderately terrible. Always #include , lest your structures magically change layout! [01:46] * duflu includes in all files from now on [01:58] Oh kdub, you put conflicts in all my code today :) [02:11] Worse than conflicts... classes don't exist any more . Hmm... [03:31] so does gdb have known issues with xmir ? [03:39] kgunn: X in general is not GDB friendly. You always have to GDB from an ssh login [03:40] or remote shell of choice... [03:41] I'm happily gdbing XMir right now. [03:41] FSVO “happily” [03:44] got it [03:59] Bah. [03:59] I should have remembered the unofficial X motto. [03:59] “X: More difficult than you think” [04:00] X: Solve everything for... [04:04] Alright. That's enough GLX bypass for now. Upstreaming! [04:06] Woo! [05:00] thomi: Sorry to bug you late in the day but any idea about... https://jenkins.qa.ubuntu.com/job/mir-clang-saucy-amd64-build/1222/console [05:25] hey kgunn! [05:25] hey didrocks ! [05:26] waow, you are using French punctuation (space before ! : and ; ) [05:27] kgunn: I confirm that u-s-c depends on libmirserver FYI [05:27] unity-system-compositor: [05:27] Depends: libboost-program-options1.53.0, libboost-system1.53.0, libc6 (>= 2.9), libgcc1 (>= 1:4.1.1), libmirserver0 (= 0.0.7+13.10.20130716ubuntu.unity.next-0ubuntu1), libstdc++6 (>= 4.6) [05:28] (this dep is automatically resolved by the linker) [05:29] didrocks: hmmm, i know it uses a "shared" header...but it must actually end up being in libmirserver [05:29] src/system_compositor.h:#include [05:29] yeah, should be that ^ [05:30] that be the one [05:31] kgunn: so, +1 on the virtual package, created by a soname (in cmake) which creates a config.h file (#define)? [05:31] didrocks: wanna join our team meeting ?....we can get all our stuff out of the way & ping you to join [05:31] didrocks: It's really fun. you know you want to [05:31] racarr: ahah :p [05:31] kgunn: oh sure, when is it? (I thought your meetings were on Thursday) [05:32] nope tonight [05:32] or this morning sorry [05:32] I was able to translate :-) [05:32] how long from now? [05:32] we start in 1/2 hour [05:33] ok, just time to get the coffee ready then! [05:33] oh sure [05:34] * racarr jealous [05:34] If I had coffee there would be no going back [05:34] racarr: caffein-free tea? :) [05:34] didrocks: One step ahead XD [05:34] heh [05:34] it's the caffeine I want. it's just the caffeine I dont want in 1 hour [05:48] didrocks: Incidentally, how do we work out when the ABI has changed for that? [05:48] Empirically? [05:48] RAOF: you mean, how do you see the ABI changed? Yeah, you have to notice that your change did that [05:48] RAOF: the integration tests will tell you that quickly I think :p [05:49] Ah, ok. [05:54] duflu: hey, I missed your message before [05:54] duflu: it looks like possibly a bzr bug? Did you retry the build? [05:55] thomi: No, I don't think I have the VPN set up any more [05:55] duflu: OK [05:57] duflu: I've just kicked it off again, we'll see if it works this time. [05:57] thomi: Ta [05:57] duflu: and I'll file a bug against bzr builder and see what the devs say [05:57] * duflu wonders if the VPN setup instructions are any simpler tnow [05:58] I'm not sure they're any simpler... but I set it up once, and have never had to touch it again [05:58] ... because I tend to wipe my machines between releases [05:58] I recommend using the network-manager-applet instructions [05:58] ahhh [05:58] I haven't done that for a few years now [05:59] duflu: perhaps you have a router that's VPN capable? Although that's not very secure, depending on who has access to your personal network [06:00] thomi, hikiko, alf_ kgunn kdub meeting [06:41] racarr: Are you still hankering for a hangout? [06:56] kgunn: RAOF: let me enlight your day/night and please approve https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 :) [07:03] duflu: looks like the re-run of that jenkins job worked. I've filed a bug against bzr-builder anyway [07:03] thomi: Yep thanks [07:09] good morning! :) [07:12] RAOF: Is a string like "Intel Corporation: 2nd Generation Core Processor Family Integrated Graphics Controller" useful enough to identify the graphics chipset for the xmir devices? [07:12] I as because that's all we get for the cert lab machines at the moment [07:13] But I guess ideally we'd get the specific model number [07:13] thomi: It's pretty good, but could be better. [07:13] ok.. as long as it's not totally useless, I'll run with it for now [07:13] Ideally we'd get a tuple of (gen, GT #). [07:13] Xorg.0.log should actually have the (gen, GT #) tuple in in. [07:14] But I can't tell at the moment, because btrfs has done it's "I'll just wedge for a couple of minutes, k" thing, and anything that hits the disc subsystem is going to hang in D state. [07:14] Ah, there we go! Hissy fit ended! [07:15] [ 6184.799] (--) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2) [07:15] That one's nice :) [07:17] didrocks, just let me know when I can have fun on the arm builders, happy to take a look [07:17] tvoss_: yeah, I pinged infinity, but no luck :/ [07:17] didrocks, no pong or "no, you can't have fun on the builders"? [07:18] no pong [07:22] I hate it when I wait a month for something to arrive, and then the wrong thing arrives [07:22] Day spoiled [07:23] duflu: :/ [07:36] alf_: You mentioned it's a problem when the ground moves under your feet and MPs become conflicted... Yes I experienced this today as I have many times already. I don't think it's a problem we can avoid completely while so many people are working on Mir simultaneously [07:36] alf_: look at https://code.launchpad.net/~didrocks/mir/remove-powerpc/+merge/175201 for the first part I guess :) [07:36] didrocks: thanks [07:36] yw! [07:38] didrocks: Agreed. My point was that if we have too many such "disruptions", it will unavoidably slow down critical work, and it is a risk we should have in mind. [07:38] duflu: ^^ [07:38] didrocks: sorry, wrong nick :) [07:39] alf_: I started to think I hadn't enough coffee :p [07:39] alf_: Yes. I guess then large changes must be justified and have high value for helping future work... which usually large changes do [07:40] For example; a driver interface. It's a large change, but has high value === alan_g|EOD is now known as alan_g === hikiko is now known as hik|afk [08:23] duflu: why do you think the graphics namespace might "go away"? [08:24] alan_g: Because it makes no sense to designate part of Mir as "graphics" and other parts not graphics. It's all intended for graphics, so we should avoid the word [08:25] alan_g: "platform" ?... [08:25] duflu: I concede that it is possible you can persuade the team to rename "graphics" to , but the namespace will still exist. [08:26] How? [08:26] alan_g: How would it still exist if it was renamed? [08:26] As, for example, "platform" [08:26] But Mir is not all intended for graphics; there's input, too. [08:26] It will still have the same contents and role [08:26] RAOF: Almost all. The statement still holds :) [08:27] In put is *at least* as big as graphics. [08:27] alan_g: Yes, true. Is your current proposal significantly different to just the namespace changes though? [08:27] I haven't looked at it all in detail [08:28] yes, it moves stuff into that namespace [08:28] duflu, if we remove graphics, we should have a namespace platform [08:29] Which is part of having a delineated garphics/platform API we can take to vendors [08:29] duflu, we almost certainly end up with prefixes like Graphics* and that's what namespaces are for [08:29] tvoss_, alan_g: Looking in more detail, I see we are moving things out of "compositor" that are platform independent. I don't think such things make sense in "platform" actually [08:30] Maybe "graphics" is just a stepping stone [08:32] "graphics" is intentionally platform independent. That's why we have android and gbm implementations. [08:33] alan_g: ... which contradicts our moving platform independent code into it :/ === hik|afk is now known as hikiko [08:34] alf_: how does ""graphics" is intentionally platform independent" contradict " moving platform independent code into it :/" [08:34] ? [08:35] alan_g: sorry, I read graphics (thinking gbm/android) is platform *dependent*, my comment is invalid [08:45] alf_: still no review on my branch? [08:49] didrocks: done [08:49] thanks ;) [09:36] * duflu goes stealth mode to avoid bugging Europe for the day (and vice versa) === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [10:28] alf_, ping! [10:28] hikiko: pong [10:28] hi [10:28] do you have some time to ask you about the miron mir? [10:30] hikiko: sure [10:31] https://lists.ubuntu.com/archives/mir-devel/2013-June/000166.html [10:31] I have this as a reference but I am not sure about my design: [10:32] mg::create_native_platform will be similar to current create_platform and leave in gbm/android [10:32] mg::create_nested_platform will be similar to create_platform and in nested_platform.cpp [10:33] and the create_native_platform_nested will call both? [10:34] if the native platform doesn't know anything about the nested platform [10:35] hikiko: @mg::create_nested_platform, as things have evolved, you can probably skip this function and instantiate NestedPlatform directly (because it will live in libmirserver) [10:35] yes but where? [10:36] if it's required that [10:36] hikiko: @mg::create_native_platform_nested, this will create a native platform configured for nested functioning (e.g. no drm, no vt) [10:36] sure but [10:36] my question is: [10:37] hikiko: you can select which platform to create in DefaultServerConfiguration::the_graphics_platform() [10:40] so I choose there to create the native_platform_nested and this does the rest [10:41] I mean I just have to load the right callback [10:44] hikiko: at that point you should create either 1. the native platform: with mg::create_native_platform or 2. the nested platform: use the NestedPlatform class. We can start with NestedPlatform calling mg::create_native_platform_nested() internally to create the native platform in "nested" mode. [10:47] got it :) [10:48] thanks alan_g [10:48] alf_* [10:48] :) [10:48] hikiko: yw [10:48] hahaha [10:52] greyback, ping [10:52] tvoss_: pong === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:21] something is flakey in our armhf tests [15:25] dear armhf machine, faster please [15:26] tvoss_, can you be more specific about the flakiness? [15:26] * bregma is not disagreeing [15:27] bregma, I'm not entirely sure, but the file-based sync mechanism should be totally reliable albeit a bit unelegant :) [15:27] however, I do see the clients starting in strace and immediately exiting with 0 [15:29] * bregma goes off to play with the synch mech [15:30] bregma, a pipe should help :) [15:51] * tvoss_ thinks that he could help the armhf build machine a little in translating to assembler [15:56] bregma, I have something like http://pastebin.ubuntu.com/5884664/ in mind [16:00] might want to epoll/signal in the wait to avoid a deadlock (does pipe() close if the writer exits without a shutdown()?) [16:01] bregma, should, feel free to adjust ... if you can take care of that sync mechanism in the acceptance tests, I willl look into the flakiness [16:01] I think it comes down to an unholy combination of buildd, kernel version, epoll and reactors [16:01] just triggered a rebuild [16:02] sure, but your rebuilds are still faster than mine [16:02] bregma, not sure :) [16:54] 1 [16:54] :( [16:55] smspillaz: ? [16:56] alan_g: older versions of byobu required you to select a screen session whenever you launched byobu [16:56] newer versions automatically resume your first [16:56] So I have a muscle-memory of byobu-1 which ends up in me saying "1" a lot [16:57] Yes I guessed that [16:57] All change is bad === alan_g is now known as alan_g|EOD [17:33] d'oh, fork() and RAII do not mix well [18:47] Hours of stress testing -> lunch [19:00] bregma, any more insight on your side? [19:02] Ah! I had one more idea and failed to leave for lunch...and then now I think I finally found it [19:02] (stress test) [19:05] well it finally makes sense why it crashes at least [19:05] NOW real lunch === racarr is now known as racarr|lunch [19:15] rvalue fun [19:46] tvoss_, I'm fairly certain there's a race condition when the socket is destroyed by multiple child processes in the tests, but I'm still looking for concrete proof .. good news is I can repro locally now (after a 6 hour build) [19:47] bregma, are you getting a pure virtual function called? Causing it to crash? (I've ran into that when attempting to close the mir server before...) [19:47] or close a connection to the server [19:48] bschaefer, there is a deadlock where the test case is waiting for a signal but the child (signaller) has exited beforre the wait begins (qhich itself is a sequencing problem) [19:48] bregma, oo different problem then :) [19:49] bregma, children should learn to wait! [19:49] indeed [19:52] bregma, \o/ [19:52] bregma, I will EOD now === racarr|lunch is now known as racarr [20:16] morning [20:17] Morning [20:27] this stress-test race is a little deeper than just adding a mutex or something struggling a bit to find a solution even now that it's found [20:29] kdub: I feel like the general theme may interest you [20:30] msh::Surface is almost impossible to use safely outside of the scope of the Session that owns it [20:31] because, say, when a surface is closed, so we have to find a new surface to focus, so we find it and get a shared_ptr [20:31] and then call surface.anything() [20:31] and then another thread closes the surface [20:32] so your msh::Surface pointer is stlil valid but surface.anything() [20:32] throws... [20:32] because the ms::Surface is gone [20:33] I guess, you need session to act as a synchronization point so rather than like [20:34] bla = session.default_surface() [20:34] bla.take_input_focus(targeter) [20:35] you can do like session.take_input_focus_on_default_surface(targeter) [20:35] and the session will hold it's internal lock preventing a close_surface from being processed [20:36] but this feels unsatisfying and unscalable [20:39] The other immediate direction that comes to mind is exposing locks out of the session as API, i.e. msh::Session::Freeze f(session);, but this seems really error prone. [20:40] So maybe what you really want, is some way to promote a surface pointer, i.e. surface.no_really_block_any_thread_that_is_trying_to_destroy_this_surface_until_the_return_value_of_this_function_is_destroyed [20:41] so now I start to think that these are transactions [20:41] and wonder what Alan's thoughts so far are on the new scenegraph model ;) [20:42] because these sort of inconsistencies, are what the hypothetical group-mind scenegraph model is supposed to be able to solve [20:43] Another random API idea: session.transcation(std::function()) [20:43] which freees the session (with a recursive mutex) [20:43] and then invokes the callback [20:43] so this way you can write like [20:44] session.transaction([&](Session& s) { auto surface = s.default_surface(); surface.take_input_focus(); } [20:44] and anything calling i.e. Session::destroy_surface [20:44] will block until your transaction is complete [20:45] It's not really a transaction [20:45] because it's not reapplicable, what is it... [20:47] it's like an atomic operation. but it's not clear what session.atomically_do means (atomic with respect to what?) [20:50] racarr, can you merge lp:~robertcarr/mir/simplify-depth-assignment with trunk? [20:50] robert_ancell: Yeah doing so now [20:50] cool [20:50] robert_ancell: I finally found the stress race :) [20:50] in a way that explained the weirdness from yesterday and everything [20:50] so uite happy [20:50] \o/ awesome! [20:51] me too :) [20:51] but the solution is a little tricky [20:51] and thomi too I expect [20:51] /unclear [20:51] hmmm? [20:51] robert_ancell: hope it clears some other stuff [20:51] too [20:51] racarr: cool! [20:52] racarr: when you have a branch with the fix, let me know and I'll review your MP and test it here [20:52] I seem to be able to trigger these things more easily than most people [20:52] XD I get it like [20:52] ALWAYS [20:52] hey, does anyone know any special fiddling required to run a system with both nvidia & intel gfx ? [20:52] within a second [20:52] apparently my CPU isn't just hyper-threaded, it's hyper-mega-awesome-threaded [20:52] i know RAOF said his ran [20:52] racarr: awesome :) [20:53] do you just load nouveau for nvidia and everything else should he "happy happy happy" ? [20:53] oops/he/be [20:54] kgunn: When I had hybrid graphics the special fiddling was always disable one in the BIOS ;) not sure if you are hoping to do more than that [20:54] nope....dandrader was trying xmir and having issues...i'll share tht [20:55] oh god. what an awful merge conflict [20:56] racarr: thx for it [20:56] :) [20:57] racarr: dandrader was looking for something fun...i told him he'd get a couple of beers from me if he solves the input lag [20:57] you mean the output lag! [20:57] or was that a dream [20:57] sometimes the team meeting is hard to remember [20:57] racarr: right [20:57] all depends....:) [20:57] and i think most correctly...yet to be determined lag [20:58] racarr: btw...i capture 2 other "please add api" tasks in the unity prep bp [20:58] 1 for osk surfacetype [20:58] and 1 for greeter [20:59] i figure you know what they are....but if not....ping dandrader for osk & mterry for greeter [20:59] I think I do [20:59] simplify-depth-assignment is the first part of the greeter fix [21:00] buttttttttttttttttttttttttttttttttttttttttttttt the second part isn't clear to me yet [21:00] ill make sure I don't lose track of them :) [21:05] robert_ancell: Merging simplify-depth-assignemtn will take a while [21:05] something...strange landed [21:05] and I can't even understand how the tests pass in trunk [21:05] racarr, np, was just checking you'd seen it [21:05] all the tests which are supposed to test depth ID [21:05] got replaced with default_depth [21:06] oh and then they pass because the expectations got reordered [21:06] to make them pass [21:06] -.- [21:31] -.- [21:31] all the surface stack ordering tests are broken [21:31] because they verify by comparing the reference to the rendering criteria and the buffer stream [21:32] but they all use stub buffers that share the same [21:32] rendering criteria and buffer stream [21:32] so by broken I mean they always pass [22:27] I think I have decided on (at least for a first proposal) this msh::Session::perform_transaction(std::function) [22:27] API. [22:27] The test is difficult to design though. [22:28] the, test should verify that during the body of the function argument to perform_transaction [22:28] calls to create/destroy surface block [22:28] it should also not be a racy test ;) [22:36] one interesting possibility, requiring some serious pthread nastiness [22:36] is first you have to pin your test thread to one core, and set pthread sched param to [22:37] SCHED_FIFO [22:37] then you create a session, and a surface and call perform_transaction [22:37] in your body, you start a new thread, which calls session.destroy_surface [22:38] oh and the new thread also needs to be pinned to the same core [22:38] so then after you strt the new thread, the test yields guaranteeing your surface destroying thread will run now [22:39] since they are both pinned to the same core, and scheduling mode is SCHED_FIFO [22:39] the thread is guaranteed to continue to run until it blocks or yields [22:40] so, in the test thread, right after you yield, you can check if the surface has been destroyed [22:40] if it has, then create_surface blocked (otherwise that thread would still be executing and will have finished destroying the surface) [22:41] err, if it hasn't* [22:41] if it has, then clearly create_surface succeeded [22:41] and you have deterministic test results, i.e. create_and_destroy_surface_block_during_body_of_transaction [22:42] robert_ancell: I notice that u-s-c has no license file!? [22:43] thomi, I guess. It has license headers [22:43] feel free to add one [22:46] I have the sick feeling that that test [22:46] would never land [22:47] robert_ancell: will do [22:50] robert_ancell: https://code.launchpad.net/~thomir/unity-system-compositor/add-license-file/+merge/175422 [22:51] I dont think it's even possible to use SCHED_FIFO without root XD [22:55] I'm not sure this test is even possible as a normal user [22:55] because threads and processes are the same to the linux scheduler [22:56] so any program that can guarantee a thread executes [22:56] until it blocks [22:56] can bring down a single core system :p [22:56] but really I just want to guarantee, that another particular thread wont execute until that thread blocks [22:57] It's not actually a realtime requirement, I don't care if the kernel lets other processes run [23:04] robert_ancell: for this autopilot test, what's the best way of figuring out what hardware is running? [23:29] what I need is PTHREAD_SCOPE_PROCESS [23:29] but it's no tsupported on linux... [23:29] lol [23:34] Really? That's odd. [23:35] RAOF: Actually linux pthread implementation seems to be roughly [23:36] the least expressive pthread implementation allowed by the specification [23:36] because of the lack of distinction between [23:36] threads and processes. [23:36] ahaha [23:36] I am not happy about pthreads atm if you can tell [23:37] You could probably rube-golberg up the behaviour you want with an extra thread, right? [23:38] RAOF: I can't figure out a way... [23:38] ie: a watchdog thread that monitors the thread you're interested in, and sets a flag when it's blocked. [23:38] can't [23:38] do that either in linux [23:39] i.e. tell if a thread is blocked [23:39] What do we mean by “blocked” in this case? [23:39] RAOF: voluntarily yielded [23:40] RAOF: So the idea is, I am developing this API like session.do_transaction(std::function) [23:40] for solving...a series of other races, the stress test stuff [23:40] so, the semantics it needs to provide are [23:40] create_and_destroy_surface_block_during_body_of_transaction_function [23:41] so as far as I can see, the only way to deterministically test that is to [23:41] start a second thread from within your transaction callback, which tries to destroy a surface [23:42] and then guarantee that that thread runs until it blocks [23:42] i.e. isn't preempted by your original thread [23:43] because otherwise, all you can say is "that thread hasn't gotten to destroy surface yet..." (or rather, whatever instruction in the implementation of destroy surface the lock is actually held on) [23:43] You should be able to parse /proc to assert that the thread isn't running? [23:43] but whatever code does that [23:44] might preempt the thread [23:44] and then it wont be running [23:45] i.e. the thread might exhaust it's timeslice and be stopped from running beore it actually blocks [23:45] so, an easy fix is to use [23:45] SCHED_FIFO [23:45] and pin both threads to the same core [23:45] but, because there is no PTHREAD_SCOPE_PROCESS [23:46] SCHED_FIFO requires root, and can bring down your entire system [23:46] lol [23:46] Eh, it's a testsuite. [23:46] They're pretty much allowed to bring down your system ☺ [23:46] piglit does all the time! [23:46] yeah but can they run as root? [23:46] / with some weird RT capability flag [23:47] Why can't they? [23:47] I dunno [23:48] I guess I just kind of assume someone would object and stop that from landing [23:48] I don't mean anyone in prticular, I just mean it sounds really [23:48] objectional [23:48] lol [23:48] BUG: Can't run tests as non root user! [23:48] haha, I guess it can just be a disabled test. [23:48] We build the packages as root already, so setting the RT capability on the tests shouldn't be _too_ bad. [23:49] mm. [23:49] ok, those are all very good points. [23:50] XD, Thank you [23:50]