[00:27] <RAOF> bjsnider: You were asking about how state trackers and drivers interact?  The recent patches to hook r600g up to the xorg state tracker would be a good example ;)
[00:34] <bjsnider> sounds like a page turner
[01:00] <bryceh> ahahaha, figured out that xvfb bug
[01:37] <RAOF> bryceh: Oooh, what's that?
[01:38] <bryceh> RAOF, after a lot of digging through xvfb code, it ended up being a bug in fakeroot instead
[01:38] <bryceh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630591
[01:38] <ubot4> Debian bug 630591 in apt "apt: apt-cache fails with current fakeroot" [Minor,Fixed]
[01:38] <RAOF> Awesome :)
[01:38] <bryceh> 829470 has the analysis
[01:38] <RAOF> Would you believe that (a) compiz is super slow running under valgrind and (b) leaks like a sieve?
[01:41] <RAOF> Which is a bit annoying, 'cause I was hoping that it'd be more obvious where (probably mesa is) leaking gem_objects
[01:41] <bryceh> ugh, firefox is substituting some sort of graphic for "ff"
[01:41] <bryceh> RAOF, I would indeed believe that
[01:42] <RAOF> ==27498== ERROR SUMMARY: 4941712 errors from 2347 contexts (suppressed: 867727 from 65)
[01:42] <RAOF> Almost as many errors as I have bytes in gem_objects!
[01:42] <RAOF> :)
[01:43] <bryceh> yay!
[02:56] <bryceh> RAOF still around?
[03:08] <bryceh> I think we could maybe test Xvfb in xserver's debian/rules, but xvfb-run depends on xauth being available so I'm not sure if we can invoke that.
[03:42] <RAOF> bryceh: Now post-lunch, yeah.
[03:42] <RAOF> We could, I guess, build-depend on xauth?
[06:02] <bryceh> RAOF, yeah that's what I'm wondering
[06:03] <bryceh> I've been experimenting with just calling Xvfb directly, but utilizing xvfb-run would give a better test
[06:03] <RAOF> There doesn't seem to be any circular dependency issue there; it just depends on libx11 and friends.
[06:03] <bryceh> ok lemme give it a go
[06:12] <tjaalton> i merged 1.10.4 yesterday, might want to pull that too
[06:12] <tjaalton> at least before you try to push ;)
[06:12] <bryceh> tjaalton, yeah saw that in git
[06:12] <tjaalton> ah, cool
[06:15] <tjaalton> i've done a procmail rule to put the git commits in a separate folder. easier to follow when no debian-x bugmail is there to distract you :)
[06:32] <bryceh> aha got it
[06:33] <RAOF> Oh, man.  apitrace is pretty awesome.
[06:34] <bryceh> RAOF, ok you can cross xvfb off your todo list :-)
[06:34] <RAOF> Sweet.
[06:35] <RAOF> What intel hardware do you have trivially available?
[06:35] <bryceh> I've pushed it to the git tree, you can roll it out when you do the 1.10.4 deploy.  Hopefully it shouldn't require any tweaking; if it does let me know.
[06:36] <bryceh> RAOF, an i945 running natty and an arrandale running oneiric but failing to run X for some reason
[06:36] <RAOF> I guess I'm particularly interested in arrandale, actually; it doesn't seem like this leak appears on GM45, so I presume gen 4 and earlier are ok, and it appears on this SandyBridge, so it looks like gen 6 is affected, leaving only gen 5 :)
[06:37] <RAOF> I'll just test that hypothesis again, though.
[06:37] <tjaalton> I have oneiric on sandybridge
[06:37] <tjaalton> so compiz leaking memory?
[06:38] <RAOF> tjaalton: Yeah; on alt-tab.
[06:38] <tjaalton> ah that, well it ceases to work after some time
[06:38] <RAOF> Ceases to work?
[06:38] <tjaalton> don't have the popup anymore, though I use the more sane traditional one :)
[06:38] <RAOF> Ah.
[06:39] <RAOF> Yeah, it's the unity alt-tab that's got problems for me.
[06:39] <tjaalton> windows do change though
[06:39] <tjaalton> here compiz is taking 860MB atm
[06:39] <tjaalton> which is kinda lot
[06:39] <RAOF> And by "problems" I mean "leaks ~25MB per alt-tab, leading to fairly rapid OOM"
[06:39] <tjaalton> heh, ok
[06:41] <tjaalton> compiz is also constantly taking at least 30% cpu
[06:41] <RAOF> Oooh, interesting.
[06:42] <RAOF> The trace of alt-tab madness has the same behaviour on my GM45, but I don't see that just running compiz.
[06:43] <tjaalton> apitrace would probably need to be packaged, no?
[06:45] <RAOF> I've got a Debian ITP up.  It does really want to be packaged, yes.
[06:45] <tjaalton> ah, good
[06:45] <RAOF> It doesn't quite work properly on compiz, but it works enough.
[06:51] <RAOF> tjaalton: Could you switch to Unity's alt-tab and check that it doesn't leak gem_objects for you?
[06:56] <tjaalton> RAOF: yeah
[06:56] <tjaalton> i mean, yeah I can do that :)
[06:58] <RAOF> :)
[06:59] <RAOF> while true; do echo "********************************"; sudo egrep "[[:digit:]]+ objects" /sys/kernel/debug/dri/0/i915_gem_objects ; sleep 5 ; done
[06:59] <RAOF> Quite useful.
[07:01] <tjaalton> hum, the default alt-tab does the same
[07:01] <tjaalton> i mean stock compiz version
[07:01] <tjaalton> had 3720 objects, now after a few it's up to 3773
[07:02] <tjaalton> and the popup does appear, after holding alt down for a few secs
[07:02] <RAOF> The stock compiz version has a known leak, but it's much smaller.
[07:02] <tjaalton> ah ok
[07:50] <tjaalton> RAOF: I can't seem to reproduce the leak on a sandybridge laptop
[07:51] <RAOF> tjaalton: Strange.  DBO's just fixed it in trunk, though.
[07:51] <RAOF> At least, for me.
[07:51] <tjaalton> the first alt-tab increases the number of gem_objects, but another one doesn't
[07:52] <RAOF> I generally did about 40 alt-tabs; that raised the bytes used by a lot.
[07:52] <RAOF> (About 1GB or so)
[07:52] <tseliot> is this still the case?
[07:53] <RAOF> With the unity in Oneiric, yes.  With the unity in trunk, no.
[07:53] <tseliot> and they're going to upload the fix, aren't they?
[08:08] <tjaalton> sigh, yet another thunderbird beta and all plugins incompatible
[08:08]  * RAOF is still soldiering on with Evolution
[08:08] <tjaalton> and addresbook just as broken as with version 6
[08:09] <RAOF> tseliot: I'm not sure if they're going to upload the fix before beta freeze; DBO's gone to bed because it's insane-o-clock where he is.
[08:12] <tjaalton> "welcome to shredder", you don't say!
[08:12] <tjaalton> (the codename of tb 7beta)
[08:12] <tseliot> RAOF: it's ok, as long as they'll upload before the release ;)
[08:12] <tseliot> s/'ll//
[08:13] <tseliot> upload it
[08:13] <RAOF> tseliot: I think it's a fair bet there'll be at least one unity upload between here and release :)
[08:13] <tseliot> what's wrong with me today?
[08:13] <tseliot> RAOF: and not leaking memory doesn't sound like a feature to me :)
[08:14] <RAOF> tseliot: Thanks for following up on that nvidia corruption-after-suspend bug.
[08:15] <tseliot> RAOF: np. Now that they've confirmed that disabling grub's fb doesn't help, I can bug Nvidia to death ;)
[09:46] <alkisg> Hi, 1 out of 10 times, after suspend/resume, I'm getting the following errors, and I have to restart X:
[09:46] <alkisg> dmesg: [ 9626.944239] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[09:46] <alkisg> Xorg.0.log: (EE) intel(0): Failed to set tiling on front buffer: Input/output error
[09:46] <alkisg> Complete dmesg: http://paste.ubuntu.com/674409/  Complete Xorg.0.log: http://paste.ubuntu.com/674410/
[09:47] <alkisg> Under which package should I report this? xserver-xorg-video-intel? Against the kernel?
[09:47] <tjaalton> alkisg: .38 is fail, intel-wise. try a newer kernel
[09:48] <jcristau> and if your gpu hangs, you want to capture the error state
[09:48] <alkisg> Ah, thank you tjaalton - that also happens with .32 and .35, but I'll try the kernel ppa
[09:48] <bryceh>  /sys/kernel/debug/dri/0/i915_error_state
[09:48] <jcristau> yeah, that.
[09:48] <alkisg> Got it, thanks a lot guys
[09:49] <bryceh> if you can reproduce against the current 3.0 kernel, upstream will be interested
[09:50] <alkisg> Sure, as long as I can get that to my lucid box... /me searches the kernel ppa...
[09:51] <alkisg> https://launchpad.net/~kernel-ppa/+archive/ppa ==>                 linux-lts-backport-oneiric               , as easy as it gets :)
[09:51] <tjaalton> lucid??
[09:51] <alkisg> Yeah sorry... I'm an LTS guy
[09:52] <tjaalton> a ton of backports then
[09:52] <bryceh> tjaalton, might be better off backporting the entire kernel rather than bits and bobs
[09:53] <alkisg> Ouch, hmm... I might just stop using suspend then, and install oneiric to another partition just for the bug report
[09:53] <tjaalton> bryceh: yeah it was running .38 already, not just drm backported
[09:53] <tjaalton> alkisg: you probably have libdrm, -intel and mesa already backported?
[09:53] <bryceh> alkisg, that probably would be a bit easier
[09:54] <tjaalton> the livecd should work as well
[09:54] <alkisg> tjaalton: I think no, I think I'm using the version from lucid-updates
[09:54] <alkisg> Thanks, livecd is probably what best suits me
[09:55] <tjaalton> actually
[09:55] <tjaalton> somehow I thought you had sandybridge, so no heavy backporting necessary
[09:55]  * alkisg is all ears...
[09:56] <alkisg> Just libdrm, intel and mesa?
[09:56] <tjaalton> but if you can reproduce it with oneiric, all the better
[09:56] <alkisg> Sure I don't think it'll take me more than half  an hour
[09:56] <alkisg> dmesg, xorg.log, and error state - anything else?
[09:57] <tjaalton> i guess that'll do
[09:57]  * alkisg will also read https://wiki.ubuntu.com/X/Reporting 
[09:58] <tjaalton> well, you can use apport-cli -p xorg
[09:59] <bryceh> alkisg, if you've booting oneiric, there is a apport-gpu-error-intel.py udev hook which *should* automatically capture gpu hangs and collect all the required data automatically
[10:02] <alkisg> Perfect, thanks again guys
[10:14] <bryceh> heh, Michael Larabel found my wayland-demos package
[10:30] <tjaalton> so it seems
[10:55] <tseliot> :)
[11:23] <ricotz> might be a dump question, but why isnt libegl1-mesa-dev depending on mesa-common-dev?
[11:25] <ricotz> RAOF, hi ^
[11:25] <tjaalton> should it?
[11:26] <ricotz> libgl1-mesa-dev depends on it
[11:26] <ricotz> so it would guess so
[11:26] <ricotz> but i might not too little about it
[11:26] <ricotz> s/not/know
[11:28] <tjaalton> well, if there are no headers importing the ones in mesa-common-dev then I don't see why it should depend on it
[11:31] <ricotz> ok, so if an application depends on libegl...-dev it should pull in mesa-common-dev by itself to use them
[11:32] <tjaalton> if it uses the headers provided by mesa-common-dev, yes
[11:32] <ricotz> i was just thinking that it is more convinient if mesa does this 
[11:32] <ricotz> that is reasonable, of course
[11:41] <tjaalton> compiz fails to run with swrastg complaining that tfp is missing, though at least glxinfo says it's there
[11:41] <tjaalton> meh
[12:47] <tseliot> tjaalton: is compiz supposed to work with swrastg?
[12:54] <tjaalton> tseliot: so I'm told, that at least gnome-shell worked with it on fedora 15
[12:56] <tjaalton> could be that it's llvm failing somehow, since it feels as if it's timing out
[12:56] <tseliot> ah, with llvm
[12:56] <tjaalton> swrastG :)
[12:56] <tseliot> right, I didn't notice the g
[13:37] <Prf_Jakob> Hmm I need to install two udev rules if I want the PRIMARY_DISPLAY_THINGY to work correctly.
[20:36] <bryceh> alright, new xdiagnose 1.1 uploaded; keep an eye out for any issues in apport bug reports...  I've been testing it and seems to be working solid, but I did a good bit of refactoring so bugs are certainly possible
[22:10] <RAOF> Prf_Jakob: The PRIMARY_DISPLAY thing is a boot-time optimisation; you can safely ignore it if you don't mind until udev has finished probing everything before starting X.
[22:10] <Prf_Jakob> ok