[00:01] <Sarvatt> oh what am i talking about, thats a kernel patch :D
[12:44] <tjaalton> bryce: great, thanks. yeah that patch can be purged now
[12:53] <tjaalton> bryce: intel; debian-experimental has 2.7.99.1, I'm willing to test that next week
[13:07] <Sarvatt> might be better off with 2.7.1, 2.7.99.1 snapshot in debian doesnt have any of the updates from 2.7.0 to 2.7.1 that fixed alot of crashes
[13:38]  * albert23 thinks 2.7.99.1 will break systems where dri is disabled, i.e. because they have width>2048 (it breaks on my 945 in that case)
[19:18] <bryce> do we have 2.7.99.1 in a ppa?  that probably ought to be sufficient for testing purposes for now
[19:57] <hyperair> bryce: if you're around, i'd like to bring your attention to the fact that dropping dh_installchangelogs completely in debian/rules ends up forgetting to install debian/changelog to /usr/share/doc/<pkg>/changelog.Debian.gz as well.
[20:02] <bryce> hyperair: I can't imagine many people care about that??
[20:03] <bryce> hyperair: anyway, file a bug, we'll look into it when there's time
[20:03] <hyperair> bryce: i do. i like to keep track of intel's driver progress, but really, i could just drop by launchpad and see
[20:04] <hyperair> it helps to... erm... increase my despair after having my hopes of a release without the memory leak + performance regression + stability issues thrashed.
[20:05] <bryce> I'll keep it in mind next time I merge.  upstream didn't put in the ChangeLog with the tarball
[20:05] <hyperair> yeah i noticed from debian/changelog.
[20:05] <bryce> sometimes I take the time to generate it myself, but this time was just copying another packager's work who had simply disabled installing it
[20:06] <bryce> hmm, I have a patch that supposedly should fix all that
[20:06] <hyperair> well yes, but the point here is that instead of # dh_installchangelogs ChangeLog, it should be just dh_installchangelogs
[20:07] <bryce> ah good point
[21:00] <hyperair> bryce: when you mentioend you have a patch that supposedly fixes all that, by all that, did you mean memory leak + performance regression + stability issues by any chance?
[21:00] <hyperair> =D
[21:00]  * hyperair has a hopeful look
[21:03] <bryce> right
[21:04]  * hyperair looks forward to seeing it in the ppa =)
[21:08] <bryce> I might post it to a ppa
[21:08] <bryce> to be honest the behavior of certain people on some of the freeze bug reports has really turned me off from working on it.
[21:10] <hyperair> i can understand.
[21:10] <hyperair> but this bug is one hell of a frustrating bug, as i'm sure you know
[21:10] <hyperair> i'm pretty sure most of the intel gpu users around are facing the memory leak problem at the very least
[21:11] <hyperair> i don't really mind the hangs. i'm used to them, and they're infrequent enough. but the memory leaks really get on my nerves.
[21:11] <hyperair> because i end up staring at my unblinking hard disk light for ~5 minutes at a time
[21:12] <hyperair> and eventually my swap reaches 100%
[21:12] <bryce> well, this patch probably doesn't fix that
[21:12] <hyperair> ah. =(
[21:12] <hyperair> what does it fix then?
[21:13] <bryce> inadvertent use of unallocated memory
[21:13] <bryce> which they think may help solve hang problems
[21:13] <hyperair> that would be a segfault, wouldn't it
[21:13] <hyperair> i see
[21:14] <hyperair> that would be a help (but i'd really love to see a fix to the memory leak)
[21:15] <bryce> I'm going to be tied up at conferences the next 2 weeks, so won't really be working on any bugs myself
[21:16] <hyperair> i'd love to work on them, but i don't think i'd understand the code.
[21:16] <bryce> also I need to focus exclusively on DRI2/UXA/KMS stuff going forward
[21:16] <hyperair> this is UXA stuff.
[21:16] <bryce> well, understanding code isn't really necessary
[21:16] <hyperair> the memory leak happens on UXA. and pretty badly too.
[21:16] <bryce> it's mostly just patching and testing
[21:17] <hyperair> hmm?
[21:17] <hyperair> you need to understand the code to write patches, don't you?
[21:17] <hyperair> unless you're saying that this patch is already upstream.
[21:17] <bryce> sure, but for the most part the trick is to analyze it from different angles, communicate what you find to upstream, and let them write the patches
[21:18] <hyperair> hmm
[21:18] <hyperair> what angles can i analyze it from?
[21:18] <bryce> well, there's an established collection of tools for analyzing memory leaks
[21:19] <bryce> so you'd run those, capture their output during leak behavior, and show anything interesting to jbarnes
[21:19] <bryce> of course, it is also useful to build and test against upstream's git tree
[21:19] <bryce> just in case there is already a fix.
[21:20] <bryce> if that works, then it is a matter of doing a git-bisect search to find the patch
[21:20] <hyperair> hmm, right.
[21:21] <hyperair> i doubt i could keep X running in valgrind anyway.
[21:21] <bryce> it's not really hard.  It's a bit technical to learn the first time through.  Mostly it's just kind of time consuming
[21:23] <hyperair> technical how?
[21:23] <hyperair> the compiling bit, the git bit, or something else?
[21:24] <bryce> compiling
[21:24] <bryce> if you've not done it before
[21:25] <hyperair> i run enough compilations a day to feel the pinch when my system screws up my i/o.
[21:25] <hyperair> i.e. swapping like crazy
[21:26] <hyperair> i'd probably just script the copying of the packaging bits to the upstream bits and then run debuild -b or something similar.
[21:26] <bryce> yeah that should work
[21:27] <bryce> probably you'd want to disable most of the patches in the package in that case (comment out the lines in debian/patches/series)
[21:27] <hyperair> however, considering that the memory being consumed doesn't seem to appear to origin from any processes in particular, and that around 1G of RAM is said to be free (according to free -m, +/- buffer/cache line) when it begins shoving everything into swap and filling it up..
[21:27] <hyperair> i'd actually reckon a guess taht the memory leaking bits are actually kernel-space.
[21:27] <hyperair> stuff leaking memory that's actually in xserver-xorg-video-intel would show up as Xorg's memory, yes?
[21:28] <bryce> definitely a possibility.  -intel has moved a lot of memory management code into the kernel
[21:28] <hyperair> mmhm
[21:28]  * hyperair groans
[21:29] <hyperair> there have been two particular pieces of software i've avoided touching the source code of in the past: X, its drivers, and the kernel (and its drivers). 
[21:29] <hyperair> frankly speaking, they terrify me, simply because they work on a level i don't understand.
[21:30] <bryce> there's an easy way to solve that ;-)
[21:30] <hyperair> O_o?
[21:31] <bryce> X is not deep magic that people think it is
[21:31] <bryce> neither is the kernel really
[21:31] <bryce> there's advanced algorithms and stuff in there, but that's nothing unique
[21:32] <bryce> a lot of the code is just register poking in hardware
[21:32] <hyperair> yeah, and that's probably the deep magic part =p
[21:33] <bryce> if you have the docs that explain what the various registers are, it isn't that deep of magic ;-)
[21:34] <bryce> anyway, most of the bits I usually have to fuss with to fix bugs is not that complicated of code
[21:34]  * bryce shrugs
[21:34] <hyperair> hahah i see.
[21:35] <hyperair> well the PM parts of the kernel certainly look like deep magic to me =p
[21:35] <hyperair> i've been messing around with uswsusp recently
[21:35] <hyperair> the usplash patch that got removed.
[21:35] <hyperair> just when i thought i fixed it, the 2.6.30rc5 kernel blew it up with a stacktrace.
[21:35] <hyperair> and i gave up.
[21:44] <bryce> oh, I didn't notice, the patch I mentioned before is a kernel patch
[21:45] <bryce> so I couldn't ppa it even if I wanted to ;-)
[21:45] <crevette> hey good evening (or day)
[21:45] <bryce> heya crevette
[21:45] <hyperair> bryce: you could talk to the kernel-team to dump it in the kernel-ppa
[21:45] <hyperair> well it's not really a ppa, it's a folder on kernel.ubuntu.com
[21:46] <crevette> I've a small question is UXA activated as the default for karmic now, I owuld like to know if I can remove my xorg.conf 
[21:46] <bryce> hyperair: nah, not without getting someone to verify it does indeed solve it
[21:47] <hyperair> crevette: Try It And See™
[21:47] <crevette> (I prefer to remove xorg.conf to stick with default behavior)
[21:47] <crevette> hyperair: :)
[21:47] <bryce> crevette: not yet, maybe after UDS
[21:47] <hyperair> bryce: i could, if you're willing to compile. i'd like to think that my kernel compiling days are over.
[21:47] <crevette> hyperair: I don't even know how to check if UXA is on or not :)
[21:48] <hyperair> crevette: grep UXA /var/log/Xorg.0.log
[21:48] <bryce> hyperair: sorry I have my hands full just building X packages for people ;-)
[21:48] <hyperair> bryce: i can understand ;)
[21:48] <bryce> hyperair: also technically I'm supposed to be taking the weekend off ;-)
[21:48] <hyperair> bryce: do you have a link to that patch anyway?
[21:48] <bryce> yeah https://bugs.freedesktop.org/attachment.cgi?id=25806
[21:48] <hyperair> ah right, it's weekend. i forgot people don't work on weekends =p
[21:48] <hyperair> normal people, thati s
[21:49] <bryce> heh
[21:50] <Sarvatt> bryce: that patch is already upstream and in 2.6.30-rc6
[21:51] <hyperair> =O
[21:52]  * hyperair wonders when it'll enter the kernel-pap
[21:52] <Sarvatt> why bother putting it in a ppa when the full kernel will probably be out in the next day or two? 2.6.30-6-7 that is :D
[21:53] <bryce> Sarvatt: sounds good
[21:54] <bryce> Sarvatt: scary how many of these "X" bugs are fixed by kernel changes...
[21:54] <crevette> :)
[21:54] <Sarvatt> yeah not a good thing for jaunty..
=== albert232 is now known as albert23