=== mlankhor1t is now known as mlankhorst
=== pete-woods is now known as pete-woods-afk
[11:43] <davmor2> anyone about yet that can help me diagnose a potential framebuffer issue on mako please
[12:00] <alan_g> davmor2: I'm about. Don't know how much I can help though. Tell a bit more...
[12:03] <davmor2> alan_g: so my screen has completely locked, when I had it on maguro it was down to an issue on the FB/hardware side of things.  I've had this once on Friday, once over the weekend and now today.  I've grabbed syslog, dmesg and logcat is there anything else that might be useful and I'll put all the info into a bug
[12:05] <alan_g> davmor2: I can have a look. But this is likely an area where kdub or AlbertA can make better, faster progress.
[12:06] <davmor2> alan_g: well I'm leaving the device in it's current state so it can wait for them
[12:09] <alan_g> OK
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
[14:21] <davmor2> AlbertA: Morning alan_g point me at you as a possibly solver of an issue I am having with mir on mako, Now and then the display just locks up when is random, I've grabbed dmesg, logcat and syslog is there anything else that might be useful for a bug?
[14:21] <davmor2> AlbertA: I'm assuming it is an issue with the fb like I had on maguro but could be wrong
[14:22] <davmor2> I've left the phone in the locked up state
=== dandrader is now known as dandrader|afk
[15:13] <davmor2> kdub: Morning.  I have an issue on mako the phone's graphics has locked up.  I have the syslog, dmesg and logcat is there anything else I can get that would be useful for a bug report?
[15:14] <davmor2> kdub: I have a feeling looking at it that it might be a fb issue like I saw before on maguro
[15:14] <davmor2> kdub: I've left the phone in the broken state
[15:15] <davmor2> kgunn: ^
[15:25] <kgunn> davmor2: sorry, we were in standup...i'll let kdub give you some pointers
[15:25] <kgunn> davmor2: are you sure its graphics that's locked up ?
[15:27] <davmor2> kgunn: I can access the phone and everything looks normal it's just the image on the screen that seems frozen, but there are no crash reports not much in the way of errors anywhere similar to the issue I had on maguro which is what made me question if it was the fb, if I restart the phon eeverything is fine till the next time it happens
[15:28] <kdub> davmor2, thos logs are the most useful
[15:28] <AlbertA> davmor2, which version of mir and unity8, etc?
[15:29] <davmor2> AlbertA, kdub: I'll add all that to the bug for you, give me 5 minutes or so and I'll throw you guys the bug number
=== dandrader|afk is now known as dandrader
[15:33] <rsalveti> alf__: any news regarding glmark2?
[15:34] <alf__> rsalveti: I am going to release a new upstream version soon (hopefully today, tomorrow morning latest)
[15:34] <rsalveti> alf__: great, thanks
[15:41] <davmor2> kdub, AlbertA: https://bugs.launchpad.net/mir/+bug/1290416  phone is still in the locked state I've added an image of what I see the phone still sleeps but when I wake it I get back to the frozen image.  let me know if there is any thing else I can grab you.  p.s. if I reboot the phone it works fine again till the next time.
[15:41] <ubot5> Ubuntu bug 1290416 in Mir "Mako locks up roughly once a day since R226" [Undecided,New]
[15:59] <AlbertA> davmor2: do you think you can attach gdb to the unity8 and unity-system-compositor processes?
[15:59] <AlbertA> davmor2: A dump of the thread states
[15:59] <AlbertA> davmor2: would probably be useful
[16:02] <davmor2> AlbertA: sure, is it just gdb unity8 <pid_of_unity8> and the same again for unity-system-compositor?
[16:02] <AlbertA> davmor2: should be
[16:02] <davmor2> give me 5 then
[16:02] <AlbertA> davmor2: I haven't tried attaching in a while
[16:03] <AlbertA> davmor2: :)
[16:04] <AlbertA> davmor2: and then thread apply all bt to dump the thread backtraces
[16:06] <davmor2> AlbertA: In theory unity8 should now be attached
[16:07] <davmor2> AlbertA: let me know if it isn't
[16:07] <AlbertA> does thread apply all bt dump anything?
[16:07] <AlbertA> "thread apply all bt"
[16:07] <davmor2> ah sorry one second
[16:10] <davmor2> AlbertA: comment 9 should be right now
[16:11] <AlbertA> davmor2: wow 30 threads...
[16:11] <AlbertA> davmor2: it probably be useful if you can dump all that to a file and attach it
[16:11] <AlbertA> davmor2: otherwise it's going to be a loooooong comment
[16:11] <AlbertA> davmor2: :)
[16:11] <kdub> only 30? :P
[16:12] <AlbertA> davmor2: well it may be only the thread ids, some older threads may have died already
[16:13] <davmor2> AlbertA: comment 10 is a file :)  I'll grab usc now
[16:15] <davmor2> AlbertA: comment 11 should be usc
[16:16] <kdub> AlbertA, kinda looks like an IPC lockup to me?
[16:16] <AlbertA> davmor2: ummm I suppose the interesting bit is all of them are blocked in swapbuffers but one thread was doing a sessionDestroyingSurface
[16:16] <kdub> I don't see a thread waiting at a driver point... will re-read the backtrace though
[16:16] <AlbertA> davmor2: I wonder if there's a deadlock there
[16:16] <kdub> yeah, or in SwitchingBundle
[16:17] <davmor2> AlbertA: No idea
[16:19] <davmor2> AlbertA: the maguro would regularly lock up in a similar fashion so it just reminded me of that especially when there were no crash files.
[16:20] <AlbertA> kdub: in usc, snapshooting seems blocked, maybe that caused the driver error
[16:20] <kdub> which comment number has the usc/unity8 backtrace?
[16:21] <AlbertA> kdub : #11
[16:21] <davmor2> kdub: 10/11
[16:21] <kdub> ah, needed to f5 the page
[16:22] <AlbertA> davmor2: in any case, these are good leads to pursue
[16:22] <davmor2> AlbertA, kdub: now is there anything else while it is in this state?  As it is my main phone so I can't receive any calls currently :)
[16:23] <AlbertA> davmor2: I think this is enough for now
[16:24]  * davmor2 waits on a +1 from kudb before rebooting the device
[16:24] <davmor2> kdub: even
[16:24] <kdub> yeah, it gives something to go on
[16:24] <davmor2> cool thanks guys
[16:24] <AlbertA> davmor2: R229 is in reference to what?
[16:25] <kdub> system image number, probably
[16:25] <AlbertA> kdub: ok
[16:25] <davmor2> AlbertA: system image number
[16:26] <davmor2> AlbertA: R226 was Fridays and is the current promoted image, R229 was released this morning
[16:26] <AlbertA> davmor2: ok, so it's probably mir 0.1.5 then
[16:27] <davmor2> AlbertA: yeap libmirclient version is listed in the top comment
[16:27] <kdub> AlbertA, system-image-cli -i will give that number
[16:28] <AlbertA> davmor2: oh, yeah I see it now
[16:28]  * kdub might add libandroid-properties1 as a mir runtime dependency
[16:29] <kdub> its already in the system image
[16:29] <kdub> it would help us detect the device name, so we can blacklist, or fail better if the android library is ran on a mesa device
=== dandrader is now known as dandrader|lunch
=== alan_g is now known as alan_g|EOD
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|bbl
=== GridCube_ is now known as GridCube
=== dandrader|bbl is now known as dandrader