[00:07] <tormod> hmm https://lists.ubuntu.com/archives/ubuntu-devel/2008-May/025471.html indicates 1.2.3ubuntu1 is fine
[00:10] <tormod> bryce, ok then the version was fine already (was also what dch -i gave me)
[00:15] <bryce> ah ok
[00:28] <bryce> needs update-maintainer run
[00:30] <bryce> tormod, uploaded
[09:05] <Ng> anyone else seeing odd resume crashes in karmic atm?
[09:05] <Ng> X sort of comes back a bit, but windows don't render properly and it'll lock up shortly after, although sysrq still works
[14:21] <d6g> I feel the performance of compiz and cairo-related software is a bit sluggish in karmic, anyone knows where should i start to figure out what is the problem? (i'm using ati mobility x300 with kernel 2.6.31-8-generic & radeon driver)
=== d6g is now known as d6g|away
[15:21] <Ng> bah, crash
[15:22] <Ng> http://paste2.org/p/410429
[15:22] <Ng> what should I do with that? kernel bug?
[17:05] <kees> Ng: that's where I'd file it.  it's kernel, but it's intel drivers driver.  kernel team should be able to redirect correctly.
[17:06] <Ng> kees: yeah that's what I was thinking. I even started filing it, but ubuntu-bug seems to be able to make firefox crash, and I got sidetracked finding the bug for that and subscribing to it ;)
[17:06] <kees> urgh, it'd be funny if it weren't so sad.  :P
[17:06] <Ng> hehe
[17:07] <Ng> it's such a weird bug, it spawns a firefox process to take you to LP and most of the time that spawned firefox gets an X error and dies, which triggers an apport request for that
[17:07] <Ng> but it's known and mdz reported it, so I feel safe in not doing anything else about that ;)
[17:07] <kees> heh
[17:28] <mac_v> anyone knows about the radeon driver and the slow FPS? is this the bug related to this issue> http://bugs.freedesktop.org/show_bug.cgi?id=21508 
[17:28] <ubottu> Freedesktop bug 21508 in Driver/Radeon "low fps with radeon driver" [Normal,New]
[17:29] <mac_v> just had a doubt since comments mention "radeon-rewrite"
[18:07] <bryce> mac_v, the radeon-rewrite stuff is in place now in karmic
[18:09] <mac_v> bryce:  i'v been using the radeon.modeset=1 , kms since the kernel -7, but i get half of the FPS i get without the kms :(
[18:09] <mac_v> its ~500 with kms but without its ~1000
[18:11] <mac_v> bryce: is there an upstream bug , you could direct me to regarding this? or is it the above bug ?
[18:14] <bryce> mac_v, hard to say, the reporters did not give much solid info
[18:15] <bryce> mac_v, but I do know that kms on -ati is known to have a performance regression, but I don't know the bug #.
[18:15] <mac_v> oh :(
[19:47] <Ng> ok, getting unusable X after every suspend now
[19:53] <hyperair> at least you're not getting random panics after every other suspend/hibernate
[19:57] <Ng> is that better than having to restart after every suspend? ;)
[19:58] <bryce> Ng, bug #?
[20:00] <hyperair> Ng: how is your X unusable anyway? all i need to do is restart compiz after every suspend.
[20:01] <Ng> bryce: just waiting for the 3g network to upload it
[20:01] <bryce> hyperair, did you test the kernel patch proposed for the compiz freeze bug yet?
[20:01] <Ng> hyperair: it might be that, I didn't actually try that. it just doesn't seem to draw windows/borders
[20:01] <hyperair> bryce: no i didn't. what patch is that?
[20:02] <hyperair> Ng: that's the exact problem. restarting compiz should do the trick. just blindly alt+f2 and type compiz ;-)
[20:02] <Ng> heh
[20:02] <hyperair> that's what i do. ended up sending compiz to a few friends if the run dialog didn't focus properly
[20:03] <bryce> hyperair, search lp for the "compiz 100% cpu" bug
[20:03] <bryce> hyperair, filed against linux
[20:03] <bryce> anyway, I think both of you have that same bug
[20:03] <hyperair> bryce: but my compiz doesn't take 100% cpu
[20:03] <hyperair> at least, i don't think it does.
[20:03] <bryce> hyperair, which is why you ought to test the patch ;-)
[20:04] <hyperair> heh yeah, considering i'm already running a patched kernel
[20:05] <bryce> 100% cpu is just one symptom, the patch fixes a number of situations where the new mesa causes failures
[20:05] <bryce> you can also try downgrading to the x-retro ppa's mesa 7.5, but that's just a workaround
[20:05]  * bryce back to bugz
[20:05] <Ng> epic 3g speed fail aside, I'm up for trying a patch
[20:09] <hyperair> bryce: i'm running a git kernel and the said patch is already in the kernel i think
[20:15] <Ng> hyperair: out of interest, what hardware are you seeing this on?
[20:16] <hyperair> Ng: i965 8086:2032
[20:16] <hyperair> 2a03 i mean
[20:17] <Ng> I'm assuming bryce meant bug 419264, and it just strikes me a little bit that people there are seeing it all over the place, I'm only seeing it on resume
[20:17] <ubottu> Launchpad bug 419264 in linux "Uses 100% CPU with latest mesa/libdrm update" [High,In progress] https://launchpad.net/bugs/419264
[20:18] <hyperair> yeah i saw that too
[20:18] <hyperair> the last comment has a commit hash
[20:18] <hyperair> which is in my git tree of the kernel
[20:41] <bryce> jbarnes, http://people.canonical.com/~bryce/Graphs/drivers.svg
[20:42] <jbarnes> woo
[20:42] <jbarnes> beating ati finally :)
[20:43] <jbarnes> looks like nvidia will be higher soon too
[20:45] <bryce> yep
[20:46] <ScislaC> 9.04? Who uses /that/? ;)
[20:46] <bryce> I wish nouveau would develop faster, I hate putting time into triaging -nvidia bugs, always seems like a waste
[20:46] <bryce> ScislaC, ;-)
=== bryce changed the topic of #ubuntu-x to: https://wiki.ubuntu.com/X
[20:47] <ScislaC> :P
[20:47] <hyperair> what was it before?
[20:47] <ScislaC> Ubuntu 9.04 released! | https://wiki.ubuntu.com/X
[20:48] <hyperair> ah
=== d6g|away is now known as d6g
=== ripps_ is now known as ripps
=== d6g is now known as d6g|away
[23:39] <Ng> hyperair: yeah restarting compiz seems to do the trick