[00:52] <dmandell> msg bryce error was "Failed to set tiling on front buffer: rejected by kernel"
[01:09] <kees> bryce: ^^ that was doug trying the -intel.  X wouldn't start with it.
[01:23] <wgrant> X segfaults with the new driver here.
[01:28] <LLStarks> hello?
[03:03] <bryce> bugger
[03:03] <bryce> wgrant, kees, dmandell, thanks for testing it
[03:12] <bryce> jbarnes: btw, regarding the performance issues, some people have been noticing that flipping on greedy migration makes the performance go back to normal.
[03:26] <bryce> wgrant: the segfault is expected (it's why we disabled it to begin with)
[04:49] <superm1> bryce, what conditions are causing the segfault?  is it caused by the way the patch re-implements enabling greedy (as opposed to turning it on in xorg.conf), or just particular hardware combos that are causing it?
[04:51] <bryce> as far as I can tell (and I could be wrong), the code that gets run is essentially the same code as gets executed when it's set in xorg.conf 
[04:51] <bryce> s/could/am probably/
[05:37] <LLStarks> stupid question, how do i sync to vblank without compiz?
[12:39] <Mirv> bryce: (bug #356951) were there mesa 7.3 deb:s available somewhere still? I could risk a crash on my machine trying those.
[12:39] <Mirv> currently running with compiz disabled on i965
[12:39] <Mirv> (or if anyone knows)
[12:40] <Mirv> the branch seems to have only DRI2-related intel-specific things since 7.4 http://cgit.freedesktop.org/mesa/mesa/log/?h=mesa_7_4_branch
[12:42] <Mirv> if someone would have a lot of time, bisecting since the last 7.3 snapshot could be worthwhile, but it would be far easier if there was some simple trigger to the problem
[12:43] <tjaalton> Mirv: superm1 already did that, but it didn't seem to help
[12:43] <tjaalton> I could give it a go this evening once I've fixed my car :/
[12:43] <Mirv> tjaalton: bisecting or what?
[12:43] <tjaalton> Mirv: bisecting
[12:44] <tjaalton> bug 355242
[12:44] <tjaalton> once of the crashers
[12:44] <tjaalton> -c
[12:45] <Mirv> ok. hmm, mobility m6 (9000) is quite far from i965, though
[12:46] <Mirv> has someone tested none of the current patches included in the packaging is causing the crashes?
[12:46] <tjaalton> oh, hehe
[12:46] <tjaalton> didn't check that it was radeon and not intel..
[12:47] <Mirv> I've quite a lot of real (paid) work to do but I could try running one specific mesa-version.. maybe I could just disable all the current patches and run it with compiz on and report on that
[12:48] <tjaalton> yeah, probably worth a shot
[12:49] <Mirv> if bryce has success with 7.3 + i965, it probably means good enough information already on that front
[12:49] <Mirv> but ok, compiling that now
[12:51] <philsf> IIUIC, the new evdev is used for autodetecting hotplugged devices, including keyboards, so there's no need for defining layouts in xorg.conf. In my case, the correct layout is detected, but with the wrong variant. 1- Does this evdev method have the ability to detect layout variants? 2- Since my particular variant is missing from the GUI, should I file a wishlist bug against what package: gnome-* for the GUI, hal-* (-info?) for the hotplug stuff?
[12:54] <tjaalton> philsf: just put it in /etc/default/console-setup
[12:54] <tjaalton> look for XKBVARIANT
[12:54] <tjaalton> restart hal, and possibly X
[12:55] <philsf> tjaalton: will it work both for console and X?
[12:56] <philsf> tjaalton: there's also the issue of the GUI recently (since Intrepid) missing this variant
[12:57] <tjaalton> which variant?
[12:58] <philsf> abnt2 brazillian layount, thinkpad variant (the right Ctrl is substituted by the slash/question)
[12:59] <philsf> I reported a bug about it (the GUI, mostly), and only now I found out about evdev/hal and such
[12:59] <philsf> Bug #359719 - now I'm not sure it's reported against the correct package
[12:59] <tjaalton> xkb-data would be better
[13:00] <philsf> is this where the GUIs gets the list of layouts/variants?
[13:01] <tjaalton> yes
[13:01] <tjaalton> (AIUI)
[13:01] <philsf> great, I'll dig more into it, thanks for the pointer
[13:02] <tjaalton> you can check the upstream git repo for a reason why it was removed
[13:02] <tjaalton> if it worked in intrepid
[13:02] <tjaalton> http://cgit.freedesktop.org/xkeyboard-config/
[13:03] <philsf> it worked in Hardy. I didn't try Intrepid, but some folks confirmed the GUI is also missing this option in that release
[13:03] <tjaalton> ok
[13:03] <jcristau> with xkb-data git, using a thinkpad model and br layout will set the thinkpad variant
[13:04] <tjaalton> ah, model
[13:04] <jcristau> probably same with 1.5 actually
[13:04] <tjaalton> most likely
[13:04] <philsf> is patching /usr/share/X11/xkb/keycodes/evdev overkill?
[13:04] <tjaalton> the evdev shuffle was before 1.5
[13:05] <philsf> (aiming at automagic detection)
[13:05] <jcristau> philsf: what would you want to autodetect?
[13:05] <philsf> jcristau: the thinkpad variant of abnt layout
[13:05] <jcristau> well. just set the model to thinkpad.
[13:06] <jcristau> keycodes/evdev would be the wrong place for this anyway
[13:07] <philsf> jcristau: I may be misunderstanding, but in my case I think both variants use the same keycode. Is it even possible to auto-detect the variant in this case?
[13:07] <jcristau> no
[13:10] <jcristau> you could put some smarts in console-setup to detect that the machine is a thinkpad and set the model appropriately on install, i guess
[13:16] <philsf> jcristau: I was thinking this was an already solved problem, and that only a small device-specific string/info/fdi was missing. could it be the case?
[13:16] <jcristau> no idea
[13:17] <philsf> ok :) should I turn the above bug bug to xkb-data instead? gnome-*? both?
[13:28] <tjaalton> just try setting the model. if it works, then no bug is needed
[13:33] <philsf> tjaalton: I had tried setting all four possible thinkpad models (as from vendor IBM in the gnome GUI), with the br layout, but the different key didn't work.
[13:36] <tjaalton> philsf: ok, in that case move the bug to xkb-data
[13:36] <philsf> I already did, thanks for the pointers (source package xkeyboard-config)
[18:12] <tjaalton> bryce: btw, I've not seen any freezes with mesa 7.4, but my -intel is 2.6.3-0u2
[18:14] <bryce> tjaalton: how long have you been running mesa so far?
[18:14] <bryce> tjaalton: and do you have compiz enabled?
[18:15] <bryce> well, certainly could be an -intel change.  If you're certain mesa is not causing it, try upgrading to u9 and see if the freezes appear
[18:16] <tjaalton> I've installed it on March 31st
[18:16] <tjaalton> and compiz is runnig
[18:16] <tjaalton> +n
[18:16] <tjaalton> suspending messes up the uptime, so I need to check when was the last time I booted it up
[18:19] <tjaalton> hmm three days ago
[18:20] <tjaalton> anyway, I'll upgrade it now to see if it'll freeze
[18:21] <DBO> bryce, I dont know if you remember talking to me or not, but I though I would mention I fixed my render performance issue simply by dropping the up_threshold on the OnDemand governor to 35 from its default
[18:22] <DBO> my battery life shortened by about 10 minutes overall, but the usability difference is huge
[18:23] <seb128> bryce: I'm use mesa 7.4 and intel 0ubuntu8 for over a week full day and didn't get any freeze there
[18:23] <seb128> I didn't do recent updates for other packages though
[18:24] <tjaalton> heh, someone on that bug is requesting mesa 7.5
[18:34] <tjaalton> superm1: have you checked libqt upstream if there are commits that fix the segfault?
[18:34] <superm1> tjaalton, there is no more development on qt3 afaik.  they've moved to qt4 development
[18:35] <tjaalton> ah, heh
[18:36] <bryce> ok so we have all combinations
[18:37] <bryce> mesa 7.4 + old -intel : no freeze, mesa 7.3 + new -intel : no freeze, and mesa 7.4 + new -intel : no freeze
[18:37] <bryce> *sigh*
[18:37]  * bryce !<3 freezes
[18:37] <seb128> I'm still running ubuntu11 for the server, could that make any difference?
[18:37] <seb128> can people having the issue ssh the box?
[18:38] <bryce> seb128: doubtful, but at this stage nothing is off the table
[18:38] <bryce> seb128: yes, being able to ssh to the box is a differentiating symptom between X freezes and kernel freezes
[18:38] <seb128> ok, and you are sure it's xorg locked? I had case where compiz was eating cpu and being the issue
[18:39] <bryce> seb128: I did so when I first got the freeze and poked around in every kernel, X, etc. file I could find, but didn't see error messages
[18:39] <seb128> (not recently but just saying)
[18:39] <bryce> hmm
[18:39] <seb128> ie you tried to restart compiz?
[18:39] <bryce> I did not try killing compiz in that case
[18:39] <seb128> worth trying
[18:39] <bryce> yeah
[18:39] <seb128> because compiz being frozen looks similar to xorg being frozen usually
[18:40] <bryce> should add that to the freeze page
[18:40] <bryce> I did reproduce a freeze by strace alarm-clock, which produced identical symptoms
[18:40] <bryce> however killing that process restored X 
[18:40] <seb128> well the clock freeze should make gnome-panel not responding
[18:41] <seb128> but workspace switches etc should still be working
[18:43] <bryce> hmm, only had one workspace set up on that machine
[18:46] <bryce> in any case, I'm not sure I like this idea of client apps freezing up X
[18:46] <seb128> they don't freeze xorg
[18:46] <seb128> the calendar case freeze the panel usually
[18:47] <seb128> which means no taskbar update, no menu, no fusa, etc
[18:47] <seb128> but you can still use nautilus on the desktop and alt tab between open applications
[18:47] <seb128> compiz freezing can lead to apparent freeze because it's grabbing events
[18:47] <bryce> well, I could not ctrl-alt-backspace (although it's enabled), couldn't vt switch, couldn't click anything with the mouse, screen did not update, etc.
[18:48] <bryce> nope, alt-tab was not working either
[18:48] <seb128> ok, so that's not the usually clock hanging issue
[18:48] <seb128> perhaps you get a hang in the middle of a dnd or something
[18:49] <bryce> supposedly strace firefox produced the same freeze situation, however I couldn't reproduce - firefox just segfaults
[18:49] <seb128> in which case the pointer is grabbed for the dnd which lead to a lock until you stop the application having the lock
[20:19] <juliux> hi is this a real bug or a misconfiguration on my side?
[20:19] <juliux> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/359960
[20:24] <superm1> jcristau, what is with those vocal users on debian bug 515214?  i guess i dont see the case that someone really doesn't want hal doing work for them...
[20:44] <tjaalton> superm1: no-one does :)
[22:07] <tjaalton> I wonder if commit 1df6716281579e (xserver) would fix the duplicate wacom entry crashes
[22:10] <tjaalton> although looking at the backtrace wouldn't suggest so, since pInfo isn't NULL
[22:12] <tjaalton> something similar might do
[22:12] <tjaalton> anyway, night ->