[11:07] <ogra_> Fatal server error:
[11:07] <ogra_> [    62.328] Inconsistent depth 24 pixmap format.  Exiting
[11:08] <ogra_> that seems to happen on all arm test installs for beta2 ... did anything in xorg change recently that makes 24bit being considered bad ?
[11:19] <tjaalton_> doubt it
=== tjaalton_ is now known as tjaalton
[11:37] <ogra_> tjaalton, well, the point is that neither the kernel, nor the binary driver nor the xorg driver changed on the pandaboard ... its all just a copy from quantal (not even recompiled afaik)
[11:37] <ogra_> so the only part failing can be xorg itself
[11:54] <seb128> bah, hate you intel driver, compiz frozen again while doing a dnd between screens and I can't restart it
[11:54] <seb128> "intel_do_flush_locked failed: Input/output error"
[11:55] <seb128> Apr  4 13:53:06 localhost kernel: [16594.405422] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[11:55] <seb128> Apr  4 13:53:06 localhost kernel: [16594.405430] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[11:55]  * seb128 reboots
[12:06] <tjaalton> seb128: maybe try 3.9rc kernel?
[12:07] <seb128> tjaalton, it's not like I was having the issue every time, I could try those, but even if that works that doesn't me a fix for raring, just a workaround for me
[12:07] <seb128> or is there a specific fix in there that you are considering asking for backport to the raring kernel?
[12:10] <tjaalton> seb128: no, but it would give some working baseline to bisect from
[12:10] <tjaalton> if it's fixed
[12:19] <seb128> tjaalton, I will try to see if I can easily reproduce and then test the new kernel if it makes a difference
[12:19] <seb128> I wonder if that's the same gpu hang that dholbach was asking about yesterday
[12:19] <seb128> seems quite frequent, I hit an hang a day on raring on my i5 laptop :-(
[12:20] <tjaalton> that's too bad.. I only get the compiz hang after user-switch on my ivybridge desktop
[12:20] <tjaalton> "only"
[12:21] <tjaalton> seb128: hey, you could test new mesa too :) https://launchpad.net/~ubuntu-x-swat/+archive/x-staging
[12:21] <tjaalton> there's a ffe for it
[12:21] <tjaalton> so it's not completely crackful
[12:21] <seb128> do you have a dual screen setup? ;-)
[12:21] <tjaalton> no
[12:21] <tjaalton> it makes a difference I bet
[12:21] <seb128> k, no luck then
[12:22] <seb128> well, the hang I just hit seems to happen when dnd between the 2 screens
[12:22] <tjaalton> 3.9 got some pageflip rewrite so it might help
[12:22] <seb128> I hit it several times this way this week
[12:22] <tjaalton> hmm, wonder if it was you or someone else who said the same
[12:25] <tjaalton> isn't the dpi hardcoded to 96 somewhere?
[12:28] <seb128> tjaalton, in GNOME?
[12:28] <tjaalton> yes
[12:28] <tjaalton> i think
[12:28] <seb128> yes, it is
[12:28] <seb128> why?
[12:28] <tjaalton> bug 1164379
[12:28] <ubottu> bug 1164379 in xorg (Ubuntu) "DPI not detected" [Undecided,New] https://launchpad.net/bugs/1164379
[12:29] <tjaalton> was about to close it as wontfix
[12:30] <seb128> tjaalton, https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c#n67
[12:30] <tjaalton> thanks
[12:30] <seb128> yw
=== kees_ is now known as kees
[21:17] <marvin24> tjaalton, mlankhorst: xserver segfaults on some ARM in xf86platformBus.c
[21:17] <marvin24> the problem is that on my machine, the pci busid is NULL around line 226
[21:18] <marvin24> and strncmp doesn't like this
[21:18] <marvin24> this is on raring btw
[21:19] <marvin24> adding a check in the if expression fixes it for me
[21:21] <tjaalton> marvin24: bug 1161981
[21:21] <ubottu> bug 1161981 in xorg-server (Ubuntu) "Boot stalls after Ubuntu Raring desktop ARM (Panda board) install" [High,Confirmed] https://launchpad.net/bugs/1161981
[21:21] <tjaalton> maybe?
[21:22] <tjaalton> yeah
[21:22] <ogra_> hmm, i just had marked that as duplicate 
[21:23] <ogra_> i thought ...
[21:23] <marvin24> tjaalton: no, xserver crashes very early
[21:24] <marvin24> before loading any module
[21:24] <ogra_> tjaalton, thats not on a panda 
[21:24] <ogra_> marvin24, thats raring, right ?
[21:25] <marvin24> http://sprunge.us/hdfT
[21:25] <marvin24> ogra_: yes
[21:25] <ogra_> intresting is that it works with a 3.1 kernel 
[21:25] <ogra_> but not with 3.8
[21:26] <ogra_> i wonder what changed 
[21:26] <marvin24> http://paste.ubuntu.com/5677653
[21:26] <marvin24> ogra_: related to pci
[21:26] <marvin24> seems pci is detected but no busid
[21:26] <marvin24> it worked a few weeks ago
[21:27] <marvin24> I also wonder what changed
[21:27] <marvin24> (it worked with 3.8 until xserver was upgraded)
[21:27] <tjaalton> it's the same bug
[21:28] <ogra_> well, then it is probably the same but manifests differently 
[21:28] <marvin24> tjaalton: at so different places in the start process?
[21:28] <ogra_> ah, to slow :)
[21:28] <tjaalton> marvin24: yes
[21:29] <marvin24> ah, just read comment #21
[21:29] <marvin24> so seems you are right
[21:30] <ogra_> awesome 
[21:30] <mlankhorst> marvin24: oh on arm we could ignore the platform string, I tried to be careful and require pci, but I guess I messed up
[21:30] <ogra_> well, there are arm boards with PCI buses
[21:30] <mlankhorst> my point is that it shouldn't have crashed to begin with
[21:31] <ogra_> i havent seen one that had a graphics card in there ever, but they exist
[21:31] <mlankhorst> that's all
[21:31] <ogra_> ah, yeah
[21:31] <mlankhorst> and it should be a straightforward fix but im asleep
[21:31] <mlankhorst> xorg-server only seems to care about busid for pci devices
[21:32] <mlankhorst> i think
[21:32] <marvin24> well, busid should be checked against NULL in any case
[21:33] <mlankhorst> oh it's loading modesetting too?
[21:33] <marvin24> well, kind of
[21:33] <marvin24> opentegra
[21:33] <marvin24> which is modesetting + some stuff
[21:33] <mlankhorst> I mean from the bug report
[21:34] <mlankhorst> worst case, I guess it has to determine another way to check if those devices are identical
[21:35]  * marvin24 is also tired 
[21:35] <marvin24> I'm off