[17:37] <federico1> tseliot: ping
[17:37] <federico1> tseliot: did you have a chance to test http://bugzilla.gnome.org/show_bug.cgi?id=572876 again?
[17:37] <tseliot> federico1: pong
[17:38] <tseliot> federico1: I haven't tested it recently but last time I tried to get a clue about what failed I didn't find anything useful
[17:39] <federico1> tseliot: ok - if you can still reproduce it, please ping me and we'll go through it
[17:39] <federico1> I basically want to see what errors out in gnome-rr
[17:39] <tseliot> federico1: ok, I think I can do some tests tomorrow
[17:39] <tseliot> I'll let you know
[17:51] <federico1> thanks!
[18:37]  * apw wonders if bryce is about ... wanted to talk about mtrrs ....
[18:38] <bryce> yep
[18:38] <bryce> apw: ask away
[18:44] <apw> bryce, ok i am having trouble maintaining mtrr's for the AGP aperture ... the i915 driver installs one at load and wants to remove it at module unload time.  however the xserver seems to eat the mtrr on exit.
[18:45] <bryce> apw: yeah, have you see the bug report about this?
[18:45] <apw> bryce, looking at the debug produced by testers it is looking like the server is trying to install and remove mtrrs every login/logout
[18:45] <apw> for the xserver?
[18:45] <apw> bug #314928 is the one i am working
[18:45] <bryce> right, bug 314928
[18:46] <apw> heh so yeah seen that, thats the one i am trying to sort out but the xserver
[18:46] <jbarnes> should probably be a GEM check around the mtrr fixup in the 2d driver then
[18:46] <bryce> ok :-)
[18:46] <apw> is mangling my mtrr, and worse seems to be doing so even it was not it that installed it
[18:46] <apw> as i would expect it to install and remove one if it was going to do so
[18:47] <apw> but it seems to fail to install one, but then does remove one
[18:47] <bryce> ok, I know very little about the mtrr handling
[18:47] <apw> jbarnes, possibly yes.  though the upstream code seems to install the mtrr for both all i915 loads
[18:47] <bryce> jbarnes: is it the driver that should be doing the check or the server?
[18:48] <apw> i am not partiucally worried if x wants to manage the mtrr, its just that x is doing half the job right now
[18:48] <apw> and removing the mtrr and failing to put it back on restart, which might mean the install code is broken
[18:48] <jbarnes> right it should be either all kernel or all userspace
[18:48] <apw> and fixing that may be sufficient
[18:48] <jbarnes> apw: you mean pre-gem i915 drivers do it too?
[18:48] <bryce> seems to be in i830_driver.c
[18:48] <jbarnes> bryce: I think the 2d drivers do it through pciaccess/X calls
[18:49] <apw> i more mean that the newer drivers are doing it always whether gem is enabled or not, and that is where we are moving towards here
[18:49] <jbarnes> right ok
[18:49] <jbarnes> yeah seems like it was just an oversight from when gem was added
[18:49] <bryce> jbarnes: can we just undef HAS_MTRR_SUPPORT during configure?
[18:49] <apw> i was back porting mtrr fixes from upstream as we have no mtrr by default in jaunty
[18:50] <jbarnes> bryce: I think it would be better to just add an if (pI830->memory_manager) or similar check
[18:50] <apw> but i am thinking that is an error, and its xorg which is broken in that it should be enabling the mtrr
[18:50] <apw> indeed from the bug it appears it is trying and failing, perhaps i should be fiddling kernel wise but we should jsut
[18:50] <apw> find out why X fails to insert it
[18:50] <apw> * i should not
[18:51] <apw> as jbarnes is correctly saying one or the other needs to own the mtrr for the aperture.  it looks like X thinks it is at jaunty revs
[19:00] <bryce> apw: ok, sounds like it is an X error
[19:02] <apw> bryce, it feels like it from outside, but i am perfectly willing to fix the kernel if its broke.  just fixing it isn't helping with X "helping out" too.  so we do need to resolve what is meant to be happening and then plan a fix
[19:03] <jbarnes> bryce, apw: see https://bugs.freedesktop.org/show_bug.cgi?id=21303 for my patch
[19:06] <bryce> thanks, I'll put that in my ppa
[19:08] <apw> bryce, let me know when its up and i can try it with my machine, and make sure the kernel is doing samething sane still
[19:08] <apw> i think we still need some change, if the kernel is maintaining it
[19:08] <jbarnes> yeah GEM needs it anyway, so the kernel is the right place for it
[19:09] <apw> yep.  just need the ducks in a line ...
[19:11] <bryce> posted here https://edge.launchpad.net/~bryceharrington/+archive/ppa - may be a bit before it gets the debs built
[19:13] <apw> an age no doubt
[20:35] <bryce> apw: hmm, ppa failed to build the package.  seems there had been a newer version in the ppa at some point or something.
[20:36] <bryce> apw: it builds fine on my system; are you able to pbuilder or dbuilder it locally?  If not, I could just toss the debs I built up somewhere
[20:36] <bryce> apw: just let me know if you prefer amd64 or i386
[20:37] <apw> i am sure i can build it, but if you have .debs' shove them on rookery, amd64 for me
[20:37] <bryce> (some days I really hate ppa)
[20:40] <bryce> apw: here you go:  http://people.ubuntu.com/~bryce/Testing/ - grab the ones labeled with the bug number
[20:42] <apw> bryce, thanks
[20:42] <jbarnes> bryce: posted a commit id that might fix lp #302227 too
[20:43] <bryce> jbarnes: on it
[20:47] <bryce> apw: hang on, I didn't do that build properly
[20:47] <bryce> apw: let me roll some corrected debs
[20:47] <apw> bryce, no problem, will likely be my am before i get to test them
[20:47] <apw> just drop me an email when they are done :)
[20:52] <bryce> apw: http://people.ubuntu.com/~bryce/Testing/
[20:52] <bryce>   xserver-xorg-video-intel_2.6.3-0ubuntu9.3~bug314928~2_amd64.deb
[20:52] <bryce>   xserver-xorg-video-intel-dbg_2.6.3-0ubuntu9.3~bug314928~2_amd64.deb (optional)
[21:09] <bryce> jbarnes: debs with patch posted
[21:09] <jbarnes> bryce: cool thanks
[21:10] <jbarnes> seems like I could spend all day, every day fixing bug and still lose ground
[21:10] <bryce> I feel the same way
[21:10] <bryce> in fact I think I could spend all day every day just reading and forwarding bugs and never get caught up
[21:10] <jbarnes> yeah and at least I get to focus on just a couple of packages :)
[21:11] <jbarnes> heh ouch
[21:11] <jbarnes> we'll have to drown ourselves in sangria in barcelona
[21:11] <bryce> well, I mostly have to ignore everything except -intel, -ati, and xorg-server anyway
[21:11] <bryce> :-)
[21:12] <bryce> ignoring the other drivers is probably going to end up biting me on the hiney as we move to KMS though.
[21:19] <tjaalton> why, no-one uses them anyway :)
[21:19] <bryce> heya tjaalton
[21:19] <tjaalton> hodwy
[21:19] <tjaalton> uh
[21:19] <tjaalton> howdy, rather
[21:19] <bryce> what's up?  haven't seen ya in a while.
[21:20] <tjaalton> slowly getting used to the new condo
[21:21] <bryce> tjaalton: cool, still enjoying the move?  Or have all the homeowner tasks worn you out now?
[21:21] <tjaalton> and thinking about upgrading my laptop to karmic
[21:22] <tjaalton> hehe, yes, a lot of space right now, but I don't know how long it'll last :)
[21:23] <bryce> I put karmic on my laptop, it seems to be going well enough
[21:23] <tjaalton> there are still a couple of curtain poles to hang, and the lights for the kitchen table :)
[21:23] <bryce> although haven't updated it recently, so what I got on there is still mostly just jaunty+misc.
[21:24] <bryce> I'm going to try to do a few merges today, but alpha1 is freezing tomorrow.
[21:25] <tjaalton> yeah
[21:26] <bryce> I'd like to see UXA switched on by default, but the quantity of bug reports open against it are worrying me.  I've upstreamed most of them, so am hoping to see progress on them in the next couple weeks, so we can switch over post-UDS.  but we'll see
[21:27] <tjaalton> well, I wouldn't worry too much about stability in karmic right now, it's a playground ;)
[21:27] <tjaalton> as long as it's moderately tested..
[21:27] <bryce> actually I care about it being stable over UDS mostly to avoid a lot of people updating while there, breaking their machine, and coming and bugging me to make it work ;-)
[21:27] <jbarnes> bryce: maybe we can have people turn it on as prep work for one of the debug sessions :)
[21:28] <bryce> jbarnes: yep certainly
[21:28] <tjaalton> bryce: right, that sounds sane :)