[01:32] <duflu> Ug. nouveau killed my system
[01:38] <RAOF> Dead as a doornail?
[01:38] <duflu> Back now
[01:39] <duflu> If only I could remember SysRq combos
[01:41] <RAOF> REISUB
[01:42] <RAOF> Although we've actually disabled all but SUB from that.
[01:42] <RAOF> olli: Good morning/evening.
[01:46] <olli> hey RAOF
[01:46] <olli> evening
[01:46] <RAOF> Various tarballs are sauntering up to U1.
[01:46] <olli> RAOF, awesome!
[01:47] <olli> thx
[01:47] <RAOF> Taking a relaxed stroll through my ADSL pipe.
[01:47] <olli> :)
[01:47] <olli> do you need me to upload something?
[01:47] <olli> it seems like there is enough time until the meeting
[01:47]  * olli counts hours until 5am
[01:48] <RAOF> About 12 :)
[01:48] <olli> 12?
[01:48] <olli> I count 9
[01:48] <RAOF> Hm. 10?
[01:48] <olli> 9h 12min
[01:48] <olli> 7:48pm here
[01:48] <olli> meeting in my cal from 5-6am
[01:49] <RAOF> Meeting is 10pm my local time, and it's 11 minutes to 12 here.
[01:49]  * RAOF checks calendar.
[01:49] <olli> hm
[01:49] <RAOF> Ah.
[01:49] <olli> I never get these TZs right
[01:49] <RAOF> No, it's 9pm my local time :)
[01:49] <olli> :)
[01:50] <RAOF> Anyway, the upload is about half done; it'll be done in plenty of time for 9pm :)
[01:51] <olli> RAOF, when you send the mail, mind suggesting an IRC channel (ask if that works... it's china...)
[01:51] <olli> and if it doesn't we can try something like gg doc
[01:51] <RAOF> On freenode?
[01:51] <olli> to just share stuff, links to files in the local fs, etc
[01:51] <olli> RAOF, yeah
[01:51] <olli> we could probably just use this one here actually
[01:52] <olli> or a randomly picked, sort of private one
[02:51] <duflu> RAOF: Have you ever observed anything like bug 1211700? It's almost as it nouveau+radeon have excessive locking which makes GL command floods from busy clients block page flipping also
[02:51] <duflu> *as if
[02:52] <RAOF> I've not seen that
[02:52] <duflu> It feels familiar. I think I came up against similar in Compiz
[02:54] <RAOF> Well, there's currently no scheduling at the GPU level, so clients are perfectly capable of flooding.
[02:54] <duflu> Ah, bug 1007299 was similar but that was mitigated with more sane XDamage logic
[03:19] <olli> RAOF, I have asked tvoss_ to reply to tim's mail, we do have some canned answer
[03:20] <RAOF> olli: About IRC, or the general "what's happening 14.04+"?
[03:20] <RAOF> Or, I guess, both? :)
[03:20] <olli> the latter
[03:22] <olli> RAOF, the Mesa U1 link doesn't work for me
[03:23] <RAOF> Grr. Let me check.
[03:24] <RAOF> Oh, man. The fact that the mesa link randomly ends in ‘Xserver’ is confusing :)
[03:31] <olli> heh
[03:36] <RAOF> olli: Check the new link?
[03:38] <olli> RAOF, wfm, thx
[03:53] <duflu> RAOF: Does this look related to the auth_magic issues?...
[03:53] <duflu> [ FAILED ] BespokeDisplayServerTestFixture.client_drm_auth_magic_calls_platform (1922 ms)
[03:53] <duflu> See bug 1212516
[03:53] <RAOF> duflu: Plausibly?
[03:53]  * RAOF checks the bug.
[03:55] <RAOF> It's not clear to me if it's related or not.
[03:57] <duflu> It sounds very close to the symptoms being discussed yesterday
[03:58] <duflu> Wow, building a kernel is much slower than it used to be.
[05:04] <jono> RAOF, do you know what the status is on the ATI blocker that is blocking Mir from updating in the archive?
[05:04] <RAOF> jono: It's being frustrating and awkward.
[05:04] <jono> RAOF, I can imagine
[05:05] <jono> still blocked I presume
[05:05] <RAOF> But it's not actually an ATI blocker; it's an IPC problem that only appears on that machine for some reason.
[05:05] <jono> ahhh
[05:06] <jono> RAOF, do you think we should hold off the call for testing for the packages in the archive until this is fixed?
[05:06] <RAOF> Maybe? It's a race condition that seems to be pretty hard to hit, though.
[05:07] <jono> I see
[05:15] <duflu> jono: https://bugs.launchpad.net/mir/+bug/1204939/comments/13
[05:16] <jono> thanks duflu
[05:17] <tvoss_> good morning :)
[05:17] <duflu> tvoss_, hi
[05:17] <tvoss_> duflu, hey there, how is it going? kernel build done?
[05:17] <duflu> tvoss_: Yes done now. I shall have to reboot and break/fix things soon
[05:18] <tvoss_> duflu, :)
[05:20] <jono> hey tvoss_
[05:20] <tvoss_> jono, hey there :)
[05:20] <tvoss_> jono, you are supposed to be offline, aren't oyu?
[05:20] <jono> tvoss_, technically
[05:20] <jono> :-)
[05:21] <jono> back tomorrow for a day and then off on Fri
[05:38] <RAOF> tvoss_: Huh. That document you linked points to a private launchpad branch :)
[05:40] <tvoss_> RAOF, oops :)
[05:40] <tvoss_> RAOF, let's see if they try to open the link then ;)
[05:41] <duflu>   /reboot
[05:45] <tvoss_> duflu, welcome back :)
[05:46]  * duflu is experimenting with mlankhorst's vblank proposals, so things are a bit jerky
[05:48] <duflu> I take it back. Not jerky, but perfect 60Hz in Mir. Only X is broken :)
[05:52]  * tvoss_ moves over to the new house
[05:55] <duflu> Too many houses to choose from?...
[05:58] <duflu>  /swap hardware
[06:17] <mlankhorst> :p
[06:30] <RAOF> mlankhorst: Probably time for me to chase up that dma-buf patch again. Have there still not been any replies, or am I just not subscribed to the right list and people aren't CCing me?
[06:30] <RAOF> Man our tests take a long time to run under valgrind!
[06:34] <duflu> Weird how nouveau renders the Mir hardware cursor visibly differently to intel/radeon
[06:34] <duflu> RAOF: *-tests --gtest_filter="*the_test_you_want*"
[06:35] <RAOF> duflu: Yeah, fair call.
[06:41]  * duflu Ctrl+Alt+De
[07:01] <mlankhorst> RAOF: poke sumits on irc, but yeah I haven't had any feedback on my fence patch either
[07:02] <RAOF> sumits-away it is!
[07:04] <duflu> mlankhorst: Your vblank patches work brilliantly for Mir. Strangely stuck at 30-45Hz in X though.
[07:05] <duflu> Maybe Compiz is just trying to do *too much* every frame
[07:07] <mlankhorst> duflu: I still get > 100 fps every time, I guess double vblank somewhere
[07:07] <duflu> mlankhorst: Well, Mir had a nice healthy 60Hz with the patches
[07:08] <duflu> And buttery smooth
[07:15] <dholbach> good morning
[07:16] <duflu> Morning dholbach
[07:16] <dholbach> hi duflu
[07:22] <mlankhorst> duflu: my gtx 480 can drive 2 panels at 2560x1440 without problem on bootspeed
[07:23] <duflu> mlankhorst: Admittedly I have only tested a G210 so far
[07:24] <mlankhorst> it's stuck on 135 mhz memory clock
[07:24] <mlankhorst> your clock is more than that
[07:25] <duflu> mlankhorst: How to force it higher?
[07:25] <mlankhorst> so trust me if it's stuck on 30 fps
[07:25] <mlankhorst> it's because of a double vblank path
[07:27] <mlankhorst> the only times boot speeds have given me issues have been when I was running real 3d applications, not the compositing manager :P
[07:28] <mlankhorst> oh and 1080p video decoding won't work on boot speeds ;P
[07:39] <mlankhorst> duflu: sec if you want to recompile the ddx you can probably kill off a vblank
[07:42] <duflu> mlankhorst: I think I've already spent enough time recompiling kernels. It's not my priority task right now...
[07:43] <mlankhorst> http://paste.debian.net/25338/
[07:43] <mlankhorst> ddx patch
[07:43] <mlankhorst> no idea if it helps though
[07:44] <mlankhorst> but it kills an extra wait
[08:02] <alan_g> duflu: have you had time to investigate bug 1212518?
[08:02] <duflu> alan_g: No, I am still focusing on bypass. Just logging other bugs as I notice them
[08:04]  * alan_g knows how that is
[09:00] <duflu> Dear radeon: Give me an error, or display my buffer. Doing neither is not very friendly.
[09:01] <alf__> duflu: is this with the dmabuf fix applied?
[09:01] <duflu> alf__: I have no idea what you mean. But I have tested up to kernel 3.10.6 and get the same bug
[09:02] <duflu> alf__: What is it? What does it do?
[09:02] <alf__> duflu: dmabuf fix = fix for not pinning video buffers to system memory that mlankhorst was working on
[09:03] <alf__> mlankhorst: does 3.10.6 contain the dmabuf pinning fixes?
[09:03] <duflu> alf__: Yeah mean for nouveau? Yes tested that and it works. But no luck with radeon... though I can't test kernel 3.11 with radeon due to other errors
[09:04] <mlankhorst> alf__: 3.11 does, which is in the archive
[09:05] <mlankhorst> I don't think it qualifies for stable, but it can be backported if you care
[09:05] <duflu> alf__: Yeah I ran into that on nouveau and confirmed 3.11 works. You mean a similar fix is required for radeon?
[09:06] <alf__> duflu: yes, it's a dmabuf issue affecting both nouveau and radeon
[09:06] <duflu> alf__: OK. I just gave up trying 3.11 on radeon due to strange errors. I'll have to go back to it
[09:11] <alf__> duflu: what problems do you get with 3.11?
[09:13] <duflu> alf__: I saw odd Mesa/kernel errors and then full system hang. But that was raring + 3.11 kernel. I will try saucy daily image now...
[09:13] <duflu> It's difficult when I can't upgrade this machine to saucy yet, and it's the only one I can put video cards in
[09:14] <alf__> duflu: why can't you upgrade?
[09:14] <duflu> alf__: It's my "stable" server/desktop
[09:15] <alf__> duflu: perhaps have an partition for unstable installations?
[09:16] <duflu> alf__: Perhaps. But that's a last resort
[09:17] <alf__> duflu: btw, I have a radeon, so if you want me to try something with saucy + 3.11 I would be happy to
[09:17] <duflu> alf__: If I need help, I'll let you know thanks. I'll live-boot saucy for the rest of the day...
[09:18] <alf__> duflu: ok
[09:22] <duflu> Wow, kernel 3.10.6 is either impressive or a little broken for me...
[09:22] <duflu> 909115392 bytes (909 MB) copied, 1.3706 s, 663 MB/s
[09:22] <duflu> (that's to an old USB stick)
[09:23]  * duflu goes offline testing hardware and kernels for a while
[09:24] <mlankhorst> oh btw about radeon...
[09:25] <mlankhorst> https://bugzilla.kernel.org/show_bug.cgi?id=60674
[09:26]  * smartboyhw doesn't understand why duflu is using a 3.10.6 kernel
[09:26] <smartboyhw> 3.10.7 just released...
[09:59] <mlankhorst> ugh
[10:11] <duflu> alf__, the latest saucy live images seem to refuse to boot... something I noticed on another machine last night. And I can't go back to alpha-2 (only available for non-Unity flavors) because that's too old to have the right kernel. So if you could do some manual radeon testing, please do... lp:~vanvugt/mir/bypass
[10:11] <alf__> duflu: ok, so anything in particular I should try out?
[10:12] <duflu> alf__: Any fullscreen hardware surface (eglplasma or egltriangle -f)
[10:12] <alf__> duflu: ok
[10:12] <duflu> alf__, thanks. I will continue trying to find a newish saucy iso that works
[10:16] <duflu> And with that, I should organize dinner
[11:00] <RAOF> olli: Good morning
[11:00] <katie> hi tvoss_
[11:00] <tvoss_> katie, hey, I have been double booked :/ cannot miss the other meeting unfortunately
[11:01] <katie> tvoss_, ok, can we re-schedule
[11:01] <katie> ?
[11:02] <tvoss_> katie, for sure, today?
[11:03] <RAOF> jammy: Hello
[11:03] <katie> tvoss_, i can do half an hour from now, or else tomorrow is better for me
[11:03] <jammy> raof: hello
[11:03] <tvoss_> jammy, hey
[11:04] <tvoss_> katie, tomorrow then
[11:04] <katie> ok, i'll put something in the calendar :)
[11:04] <jammy> tvoss_: hi, nice to talk to your guys again :)
[11:27] <tvoss_> apt-cache policy unity-system-compositor
[11:27] <tvoss_> unity-system-compositor:
[11:27] <tvoss_>   Installed: 0.0.1+13.10.20130813.1-0ubuntu1
[11:27] <tvoss_>   Candidate: 0.0.1+13.10.20130813.1-0ubuntu1
[11:27] <tvoss_>   Version table:
[11:27] <tvoss_>  *** 0.0.1+13.10.20130813.1-0ubuntu1 0
[11:27] <tvoss_>         500 http://de.archive.ubuntu.com/ubuntu/ saucy/universe amd64 Packages
[11:27] <tvoss_>         100 /var/lib/dpkg/status
[11:27] <tvoss_> tvoss@x220:~/.phoronix-test-suite/test-results$ apt-cache policy libmirserver1
[11:27] <tvoss_> libmirserver1:
[11:27] <tvoss_>   Installed: 0.0.9+13.10.20130813-0ubuntu1
[11:27] <tvoss_>   Candidate: 0.0.9+13.10.20130813-0ubuntu1
[11:27] <tvoss_>   Version table:
[11:27] <tvoss_>      0.0.9+13.10.20130813-0ubuntu1 0
[11:27] <tvoss_>         500 http://de.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
[11:27] <tvoss_>  *** 0.0.9+13.10.20130813-0ubuntu1 0
[11:27] <tvoss_>         100 /var/lib/dpkg/status
[16:28] <mterry> racarr, heyo!  Got a sec to talk about mir sessions in u-s-c?  I'm testing on my nexus4 and the_shell_session_container() seems empty (yet mir/lightdm/u-s-c seem to be up and I see things on the screen).  What populates that list?  (seems to be sessionmediator in mir, but not sure what calls its connect() method)
[16:40] <alan_g> BRB - I've broken VT switching, need to restart some stuff
[17:25] <racarr> mterry: the protobuf_message_processor
[17:26] <racarr> but if things are working the session container is almost certainly being filled
[17:26] <racarr> you could check for open session, etc, well "connct" with
[17:26] <racarr> MIR_SERVER_SESSION_MEDIATOR_REPORT=log
[17:26] <racarr> perhaps, you are getting the_shell_session_container in a weird way
[17:26] <racarr> i.e. if you just store the CAchedPtr return value
[17:26] <racarr> err
[17:26] <racarr> well, you need to hold
[17:26] <racarr> a strong reference to it
[17:26] <racarr> or you might end up with two
[18:27] <mterry> I got disconnected, resending in case I was already timed out...
 racarr, sorry, was away for lunch
 racarr, it seems that it's filled from platform-api.  So apps themselves might fill it...  but I think the shell/greeter aren't.   Not sure if they should or even if I'm reading the situation right
[18:28] <racarr> mterry: Ah ok
[18:28] <racarr> it's filled from the RPC layer as basically
[18:28] <racarr> the session is like connection or something
[18:28] <racarr> there is no session for shell/greeter surfaces.
[18:29] <racarr> i.e. inprocess
[18:29] <mterry> racarr, but don't they act as a client for the u-s-c?  I'd think they'd call mir_connect to connect to the system mir
[18:30] <racarr> no, so
[18:30] <racarr> we don't have nested mir at the moment, but lets say we did and then
[18:30] <racarr> there is USC, which iwll jjust hve one session
[18:30] <racarr> "session mir"
[18:30] <racarr> and the session mir has application sessions, and shell surfaces, etc.
[18:30] <racarr> in the session mir
[18:30] <racarr> the shell surfaces, are all inprocess clients
[18:30] <racarr> so there is no mir_connect, and no session
[18:31] <racarr> there could be a session of some sort invented I guess. haven't come up with a usecase/sensible way to do it so far
[18:35] <mterry> racarr, shell surfaces are inprocess clients to what?  To their own mir servers?  But aren't they also clients to the u-s-c?  So they'd do a mir_connect to it, I would have thought.  I guess I'm missing how u-s-c views the shell surface, if it doesn't think of them as a client session...
[18:35] <racarr> mterry: u-s-c never sees shell surfaces
[18:35] <racarr> u-s-c just sees
[18:36] <racarr> greeter, maybe bootsplash and stuff like that, and one surface
[18:36] <racarr> for each user session
[18:36] <mterry> racarr, ok, sorry.  I guess when I said 'shell surface' I meant user session surface
[18:36] <racarr> oh ok like the whole
[18:36] <racarr> session
[18:36] <racarr> that
[18:36] <mterry> racarr, so greeter/user should be registered as sessions in u-s-c, right?
[18:36] <racarr> should be in the_session_container yeah
[18:37] <racarr> but, we don't have nested mir at the moment so you couldn't actually do that right?
[18:37] <mterry> OK, I'm not seeing that now.  So somewhere that's being messed up (and may be my own patches...)
[18:37] <mterry> racarr, we don't have nested mir?
[18:37] <mterry> racarr, how is u-s-c supposed to work then?
[18:37] <mterry> just xmir?
[18:37] <racarr> yep just xmir
[18:37] <racarr> nested mir is still in progress
[18:37] <racarr> some parts of it started to land
[18:38] <mterry> racarr, ok.  So maybe I'm still getting ahead of myself.  :(   /me is eager to try to test whole system integration with a split greeter on phone
[18:38] <racarr> :(
[18:39] <racarr> you could use little Qt apps that display a picture as fake session clients of u-s-c
[18:39] <racarr> to get things going
[18:39] <racarr> it just wont be as satisfying lol
[18:39] <mterry> racarr, well, I'm actually able to get the greeter and shell to be run by lightdm
[18:39] <mterry> racarr, but they don't seem to talk to u-s-c at all, and I can't switch between them
[18:40] <racarr> I don't know what exactly is going on byt my guess is its just
[18:40] <racarr> two entirey seperate mir servers
[18:40] <mterry> hrm
[19:52] <thomi> morning
[19:58] <bschaefer> hmm there seems to be a recent memory leak in: mir_connection_create_display_config
[19:58] <bschaefer> http://paste.ubuntu.com/5990319/
[20:00] <bschaefer> as the eglapp is calling the correct destroy function as well...so it appears to be mir hanging on to something?
[20:13] <bschaefer> found the leak :)
[20:15] <bschaefer> when anyone has time: https://code.launchpad.net/~brandontschaefer/mir/clean-up-config-cards/+merge/180413
[20:17] <arsson> unity8
[21:07] <jono> olli, which BP tracks the composite bypass work?
[21:53] <jono> tvoss_, olli, http://www.jonobacon.org/2013/08/15/mir-update-and-testing-mir-in-ubuntu-13-10/
[21:57] <tvoss_> jono, thx
[21:58] <jono> https://wiki.ubuntu.com/Mir/GPUTesting is growing :-)
[21:58] <racarr> oh wow!
[22:04] <arsson> you could add geforce gt420 to failure for now
[22:24] <arsson> but when using propreitary graphics driver it fell back to X