[00:03] michaellarabel: btw I think you need a s/Intel/Canonical/ in the second to the last paragraph on http://www.phoronix.com/scan.php?page=article&item=ubuntu_netbook_performance&num=8 [00:03] "As of this week, Intel is looking at fixing some of the performance problems when using EXA with Intel graphics by enabling the greedy migration heuristic by default." [00:07] oops, yeah. Fixing now. [02:18] bryce: btw I wonder how the perf would look with my exa pixmap management patch (the one I added to freedesktop 20739) [02:18] Freedesktop bug 20739 in Driver/intel "[i945] X crashes in fbBlt() when using Sun Java Plugin 6 + firefox3.0 on Asus EEEPC 1000" [Critical,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=20739 [02:19] jbarnes: I set up a ppa for it - https://edge.launchpad.net/~bryceharrington/+archive/blue [02:19] cool [02:20] jbarnes: not sure why manoj has not responded on that bug... he was in a dither about it when he first filed it, but strangely went silent the past week [02:21] man, I wish we had an automated phoronix set up that I could just point at a ppa or a patch, and have it automatically give results [02:22] that would be cool [02:42] Matthew Garrett is currently: angry [02:53] pwnguin: ?? [02:54] "Seriously Intel. Sort it the fuck out." [02:54] http://mjg59.livejournal.com/110535.html [02:57] * bryce shudders at memories of psb support [04:46] i've got a set of patches to fix that radeon mesa bug too now. just need to narrow it down and see if they're all necessary, or if I can fix it with just one [04:46] (bug 341898) [04:46] Launchpad bug 341898 in mesa "MythTV Frontend does not work with RADEON DRI" [High,Confirmed] https://launchpad.net/bugs/341898 [05:14] tjaalton, bryce the patch got a basic look over from arlied in #dri-devel, so i'd like to squeeze this in if we could. were you guys gonna make any changes to the other applied patches regarding the intel issue? [05:15] or were you saving those for SRUs instead [05:15] er s/arlied/airlied/ [05:28] superm1: I'd need to read the backlog first :) but yes, I'd be ok with that patch [05:28] and editing .git/config should be enough to allow pushing [05:29] yeah finally got it pushed earlier [05:29] change the url to ssh+git://foo-guest@ [05:29] i just ended up doing ssh://foo-guest@, didn't realize ssh+git:// was a protocol [05:29] ah, both should work [05:30] just noticed that I had that [05:30] so are you guys doing any other intel deltas to mesa that should go in this same upload, or just treat them mutually exclusive? [05:30] I'm not sure, bryce? [05:30] it probably doesn't matter if there's one more upload [05:31] okay. [05:32] so hopefully i don't need to touch mesa for a long time now, debugging these has been very difficult :) [05:42] here's hoping ;) [08:14] superm1, tjaalton: I'd also be okay with dropping 103 in mesa [08:14] bryce_: cool [08:15] I think I'll ask my boss (and wife) if there's a chance to get to the UDS.. [08:16] what it gains is not something that was available in intrepid, thus is not a regression. And if it eliminates even just some of the freezes, it's a win [08:16] yeah [08:16] tjaalton: that would be great if you can come! Did you get on the sponsorship list? [08:17] bryce_: no, but I think my boss could send me.. that way I wouldn't have to spend my holidays to get there [08:18] ah good [08:18] we are moving in two weeks, so we should be settled a month from now [08:20] +down [08:23] the specs are just too interesting to miss ;) [08:24] :-) [08:24] yeah I got some presentations to write [08:24] oh hell what is the cat up to [08:24] brb [08:24] :) [08:28] left the cupboard where we keep the TP open [08:28] apparently toilet paper roll wrappers make a nice crinkley sound when you sink your claws into them... [08:30] anyway, I got sick of debugging the freeze bugs blindly. I'm going to package up cworth's tools tomorrow and stick them in a ppa. We already have the 2.6.30-rc2 kernel so the hard part's done [08:31] heh [08:32] yep, it's really frustrating.. [11:09] my i965 is btw GMA X3100 (mobile GM965), if interested. indeed with the max texture size jaunty seems now rock stable even on heavy duty (like compiling and installing ubuntu in virtualbox at the same time, while spinning the cube and browsing the web) [11:09] again I missed some words, "with the max texture size patch disabled" I meant [11:30] what's the max texture size in your case? [11:35] read the second comment too :) [14:55] are i815's running xaa by default? (i.e., with an empty xorg.conf, they're running xaa?) [15:27] cwillu: probably yeah [17:16] tjaalton: btw what's the status on the mesa upload with 103 disabled? [19:01] bryce: it was discussed on #u-d a couple of hours ago, but I don't know how it ended :) [19:01] just got back [19:01] bbiab -> [19:12] tjaalton: ok I've committed the change and will upload it at this time [19:18] bryce: great, thanks [19:18] bryce: I wonder if it's patch 104 giving you the trouble? [19:18] but not Mirv or me [19:18] tjaalton: jesse also pointed me at https://bugs.freedesktop.org/show_bug.cgi?id=20704 [19:18] Freedesktop bug 20704 in Server/general "memory leak: Keep resizing glxgears window with compiz will make X hang" [Major,Reopened] [19:18] it _shoudln't_ matter if exa is used, but who knows [19:19] oh [19:20] sounds like fun, I'll try it.. [19:22] heh, I could use my laptop as an instrument [19:23] there's this high pitch squeak with glxgears running, and the pitch changes with the size of the window [19:23] the larger it is, the lower the pitch [19:24] ouch sounds like one of your input gains might be turned up too high? [19:24] hehe [19:24] it's not coming from the speaker :) [19:24] ooh [19:25] with nice tremolo [19:25] actually more like a vibrato :) [19:26] it's leaking memory, but not that much [19:28] plugged the charger and now the sound is gone :( [19:29] I need a new battery [19:30] buzzing battery doesn't sound good [19:30] yeah, it's broken alright [19:31] when I log in I get a popup saying that the charge is 48% and that it means the battery is likely broken [19:31] it's been acting weird for some weeks now [19:34] howdy folks [19:35] heya mdz [19:36] ooh "installation complete" on my shiny new jaunty install [19:36] bryce: I'm now on my affected laptop [19:41] bryce,jbarnes: I saw mvo's comment on the bug that PCI ID 8086:2a02 may be a common thread [19:42] that matches what I have as well [19:42] I'm not sure if that just means "GM965" or if it's more specific [19:42] it looks like there are only two PCI IDs with that name [19:43] #define PCI_CHIP_I965_GM 0x2A02 [19:44] yeah 2a02 is 965GM [19:44] bryce: would my time be better spent testing rolling back that mesa patch, or on trying to find a reproducer? [19:45] I'd say reproduce first, otherwise you won't know if the rollback works [19:47] I'm using 00:02.0 0300: 8086:2a02 (rev 0c) and I've no hang freeze and speed issue [19:47] seb128: with or without the mesa patch? [19:47] and I'm using this box full time with compiz one [19:47] stock jaunty [19:48] no xorg.conf change (out of virtual for multi screen) [19:50] mdz: yes, start by verifying you have the issue [19:50] vs. having seb's luck [19:51] seb128: and you switch workspaces a lot :) [19:51] seb128: rev c as well, just like the bug reporter ... [19:51] mvo: yes, I've my mailed full screen on one screen and IRC on an another screen, I think I switched several time by minute all day long [19:51] mailed -> mailer [19:52] I always switch using the keyboard shortcuts if that makes any difference [19:52] for me, it reproduced mostly with doing alt-tab [19:53] I've been aqble to recproduce the bug with only a minute or so of tinkering [19:53] well, a freeze anyway [19:55] mdz-mini: do you have steps? [19:55] mdz-mini: wow, excellent [19:55] mdz-mini: on your t61? [19:56] mdz-mini: check that you can ssh into the machine and check your syslog to rule out just a kernel bug [19:56] mvo, yes [19:56] bryce, yes I can [19:56] ok good, so chances are high you've got this issue [19:56] rickspencer3, I played a movie on workspace #4 then switched from workspace 1 to 5 and back many times [19:57] * rickspencer3 tries [19:57] ah a movie [19:57] mdz-mini: what format moving? [19:57] movie I mean [19:57] rickspencer3, happened to be an mp4, but this happened with DVD as well [19:57] I used totem [19:57] totem-xine [19:57] k [19:58] I have a shell on the machine [19:58] nothing in dmesg [19:58] nothing in Xorg.0.log [19:59] X server backtrace: [19:59] #0 0x00007f2522cdbcd7 in ioctl () from /lib/libc.so.6 [19:59] #1 0x00007f2520c493bd in drm_intel_gem_bo_start_gtt_access () from /usr/lib/libdrm_intel.so.1 [19:59] #2 0x00007f251003a241 in intelFinish () from /usr/lib/dri/i965_dri.so [19:59] #3 0x00007f2521948ac6 in __glXDisp_SwapBuffers (cl=0xac8d530, pc=) at ../../glx/glxcmds.c:1425 [19:59] #4 0x00007f252194bde2 in __glXDispatch (client=0xac8e120) at ../../glx/glxext.c:523 [19:59] #5 0x000000000044e304 in Dispatch () at ../../dix/dispatch.c:437 [19:59] #6 0x0000000000433d8d in main (argc=10, argv=0x7fff2d101828, envp=) at ../../dix/main.c:397 [19:59] is that after trying to kill X or sysrq or something? [20:00] no [20:00] haven't touched it [20:00] hmm, anyway, drm_intel_gem_bo_start_gtt_access has been associated with the freeze bug, so that's not unexpected [20:00] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/327844 [20:00] Ubuntu bug 327844 in xserver-xorg-video-intel "[G45] X freezes about 1-5 min after switching compiz on" [High,Triaged] [20:01] although this is one of those cases where the symptoms aren't an exact match for the "traditional" bug [20:01] this is one I'm confident I can reproduce === rickspencer3 is now known as rickspencer3-afk [20:02] I'm running two movies now, and can't freeze my 'puer [20:02] I'm going to run rotate forever for a while [20:02] hm, different pci id for this one: 8086:2e22 [20:06] hm I still don't see it even with movies [20:07] strace shows it looping with: [20:07] ioctl(12, 0x400c645f, 0x7fff2d1015b0) = ? ERESTARTSYS (To be restarted) [20:07] --- SIGALRM (Alarm clock) @ 0 (0) --- [20:07] oh speaking of strace [20:07] there's another insta-freeze bug if you run 'strace alarm-clock' [20:07] but it goes away if you pkill alarm-clock [20:08] supposedly, ditto strace firefox, although I couldn't reproduce that one [20:09] rebooting, will try again with more debug symbols [20:09] bryce, /topic in this channel is stale ;-) [20:09] hehe [20:09] I happen to be using an external lcd display === bryce changed the topic of #ubuntu-x to: Ubuntu 9.04 Coming Soon! | https://wiki.ubuntu.com/X [20:10] significantly larger pixel-wise than the built-in one [20:10] so working the gpu a bit harder I suppose [20:10] mdz-mini: mirrored or extended? [20:11] bryce, I turn off the buil-in [20:11] built-in [20:11] ok [20:11] what resolution is the external monitor? [20:11] I'm going to try to reproduce on the built-in display to see if that's a factor [20:11] jbarnes, 1920x1200 [20:11] well, patch 103 involves desktop size, so it could fit our theory === rickspencer3-afk is now known as rickspencer3 [20:12] I was also thinking of the infamous pipe underrun [20:13] the debugging for that has unfortunately been removed (it was incompatible with kernel interrupt handling) [20:23] humm [20:23] after a cold boot, I'm having trouble reproducing [20:23] tjaalton, superm1: I'm seeing something funky in the mesa git tree [20:23] I'm spinning a patch for pipe underrun debugging now [20:23] bryce: shoot [20:24] bryce: what do you see? [20:24] tjaalton, superm1: when I do a debuild from in the git tree, I get different results than if I do a debuild off of apt-get source mesa [20:24] .gitattributes | 4 ++++ [20:24] debian/changelog | 8 ++++++++ [20:24] debian/patches/series | 2 +- [20:24] progs/demos/extfuncs.h | 15 +++++++++++++++ [20:24] progs/glsl/readtex.h | 26 -------------------------- [20:24] 5 files changed, 28 insertions(+), 27 deletions(-) [20:24] the .gitattributes progs/demos/extfuncs.h and progs/glsl/readtex.h are mystery changes [20:25] I can't see evidence of them in recent git changes though [20:25] from a debdiff? [20:26] I decided to do my mesa patch off of the apt-get source mesa, so our upload is clean [20:27] the extfuncs.h change seems to be adding some glVertexAttrib1fv_func variables [20:27] the readtex.h change appears to be deleting that header entirely [20:28] git says my tree is clean though... [20:28] but where is that diffstat from? [20:28] readtex.h doesn't exist in git afaict. and never has [20:28] tjaalton: I did an apt-get source mesa, which gave me a 0ubuntu2 dsc [20:29] stuff in progs/demos shouldn't matter, they're just test programs [20:29] tjaalton: I committed my changes to disable patch 103, then did a debuild -S to produce a 0ubuntu3 [20:29] then I debdiff'd those two and got the above [20:29] jbarnes: yeah I know, this is totally innocuous, however it worries me that there is any discrepancy at all [20:29] yeah it's a bit weird [20:29] jbarnes: likely it's just my crappy git skillz [20:30] progs/demos/extfuncs.h is in the tarball but not in git afaict [20:30] jcristau: hmm, seems to be in my copy [20:31] of the git tree [20:31] tjaalton: hrm. [20:31] but not known by git [20:31] so this might be due to _my_ sucky git fu :) [20:31] tjaalton: btw there was also a patch 05 (not in series though) [20:32] bryce: that I can't see :) [20:32] ok, that one probably was me then :-) [20:32] i usually do 'git clean -dnx' to see if my working copy has changes wrt git [20:32] hehe [20:32] Would remove lib/ [20:32] Would remove patches/ [20:32] Would remove progs/demos/extfuncs.h [20:32] Would remove progs/glsl/readtex.c [20:32] Would remove progs/glsl/readtex.h [20:32] Would remove src/glx/x11/depend [20:32] wtf [20:33] oops :-) [20:33] git clean -dnx looks clean in my copy [20:33] still haven't seen it on my 965 [20:33] i try to always look at git status before i do a commit and git diff just to make sure i'm only committing what i want to [20:33] never heard of git clean before [20:34] mdz-mini: any luck reproducing? [20:34] * bryce appends to "git commands and options to know" [20:34] superm1: did you upload 0u2 based on 0u1 or the git tree? [20:35] I suspect the former [20:35] jbarnes, not since the cold boot. still trying [20:35] tjaalton, i apt-get source'd mesa, added my patches, and then added the same patches to the git tree [20:35] so yeah the former; was that wrong to do? [20:35] superm1: well, more work for you :) (but it confirmed that it's my tree that's buggy) [20:37] i also generally do a debdiff between dsc's for packages i've not worked with before to make sure their build systems and/or vcs' aren't injecting new stuff that i dont expect in the debdiff [20:38] is there any reason to suspect it's related to suspent/resume? [20:38] that would explain why it occurs infrequently for some [20:39] the apr 3rd freeze has not been definitively associated with suspend/resume [20:39] however there have definitely been reports about X freeze issues relating to resume [20:39] mine dies if I've booted attached to the dock [20:40] it seems to need to be in a certain state, but I'm not sure how to get it there [20:40] when I woke it up after being suspended all day, it was easy [20:40] mdz-mini: if jesse's right, it might be a memory issue [20:41] so either a memory region has to fill, or has to get filled with the right combination of stuff [20:41] jbarnes, is there an easy way to get the X server to allocate lots of chunks of memory? [20:41] I have four gigs, so it could well be hard for me to reproduce [20:41] suspend/resume could definitely change global chip state that we don't restore [20:41] tjaalton: boot with mem=1G? :) [20:41] btw; 20:50 < agd5f> r6xx/r7xx 3D driver pushed [20:41] mdz-mini: running lots of GL apps pounds the memory manager pretty hard [20:41] or stuff like openarena or other big apps [20:42] jcristau: good idea, and actually only 3G is available anyway :) [20:43] it has leaked 200meg so far, in 2h [20:44] there, no swap [20:45] oops suspend/resume failed... seems to have crashed my X server (had a video playing) [20:45] tjaalton: sweet [20:45] ok I just reproduced again [20:46] ok, I'm going to go snag some lunch, then work on the freeze debug tool packaging. be back shortly [20:46] ah no wait X is up, but hung [20:46] yep in start_gtt [20:46] right after resuming [20:46] So I just ran the rotate forever script with 100ms sleep with three movies running on three desktops [20:46] different stack trace [20:47] 25 minutes later, the system is working fine [20:47] jbarnes, we have a different bug# for that [20:47] I think [20:47] for a freeze directly after resume [20:48] latest stack trace [20:48] http://pastebin.ubuntu.com/153009/ [20:48] we would almost need a table about who is trying what on which chipset and which driver [20:49] but at least I can fairly surely say the ~bug359392 packages from PPA work as well as did my own build without the max texture patch. used for 10 hours and now having the rotate script running [20:50] Mirv: do you have plenty of RAM? [20:50] tjaalton: 2 gigs [20:50] pretty standard these days I guess [20:50] jbarnes, what sort of info might I be able to get from it while it's hung? do you want a login? [20:51] reg dump [20:51] or if you have the kernel package & gpu tools package you could get a batchbuffer dump [20:51] jbarnes, regdump: http://pastebin.com/f38c68b88 [20:52] mdz-mini: so did you have to suspend/resume to reproduce it? or just plug in the external monitor? [20:53] jbarnes, when I had trouble reproducing, I tried suspend/resume a few times, then launching more apps, then adding some glxgears instances [20:53] ok so at least one suspend/resume was required... [20:54] the setup when it finally froze was video + browser + 2xglxgears + terminal all on separate desktops [20:54] after a few suspend/resume cycles [20:55] not sure which elements were essential [20:56] if I could get it unwedged it would be interesting to try again with the same instance of the server [20:56] * rickspencer3 tries suspend/resume then repro === rickspencer3 is now known as rickspencer3-afk [20:57] jbarnes, bryce is it more useful for me to keep trying to distill this down to a simpler reproducer or to try to analyze the frozen state? [20:59] the register dumps didn't have anything interesting that I could see [20:59] w/o the kernel patches I'm not sure there's much else we can grab unless dmesg has an oops or something [21:00] no such luck [21:01] if you can reproduce it fairly easily (maybe try a few more times) then you could start bisecting [21:01] i915_wait_irq /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7 [21:01] (wchan) [21:01] yeah it's just waiting for some rendering to finish [21:01] cool mine hung in suspend this time [21:02] totally wedged [21:02] ug [21:03] with the PPA mesa, I'm (i965 2a02, 2GB RAM) now running successfully rotate-forever with Flight Gear, full screen looping video, firefox and two glxgears while doing suspend-resume-cycles. I guess I could try with mem=1G and see if I get it to hang. [21:04] Mirv, I think we're talking graphics memory here rather than main memory [21:06] mdz-mini: well, I guess intel allocates it from the main memory relative to its size, as it does not have own integrated memory usually [21:06] yeah gem allocates from main memory [21:06] and swaps stuff in and out of the graphics mapping [21:07] mdz-mini: boiling down the steps to reproduce would be the most helpful [21:07] bryce, ok, I'll start working on a script [21:07] bryce: did you btw have a) amd64 b) less than 2GB of RAM? and 2a02? [21:07] mdz-mini: at some point I'll want you to also put on the 2.6.30-rc2 kernel and verify you can still reproduce it there, since the debug tools have to be run on that kernel [21:08] Linux salisbury 2.6.28-11-generic #41-Ubuntu SMP Wed Apr 8 04:38:53 UTC 2009 i686 GNU/Linux [21:08] MemTotal: 1534756 kB [21:09] 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) [21:09] Subsystem: Dell Device [1028:01f3] [21:09] jbarnes, doesn't it allocate a fixed chunk regardless of how much main memroy there is? or am I confused? [21:09] mdz-mini: no not anymore... with GEM it's all dynamic [21:10] fun [21:11] jbarnes: btw fyi, gpu tools which don't need to be run as root, we can add to apport (our automatic bug reporting script) [21:11] cool [21:11] bryce: ok, I was just guessing if somehow dropping 103 only helped amd64 users, but I've yet to check if tjaalton is also running amd64 [21:11] I'd guess the big ones need root though, since they access debugfs files [21:11] jbarnes: intel_reg_dump unfortunately appears to need root, which is why we aren't including captures of that for all bug reports (tho would be nice if we could) [21:12] Mirv: 32bit [21:12] tjaalton: ok, not a factor then. less than 2GB memory? [21:13] Mirv: no, 3 [21:13] mdz-mini: another thing to check would be to see if you're still getting gfx interrupts after the hang [21:13] grep i915 /proc/interrupts [21:13] tjaalton: ok, some magic then might be in having less than 2GB memory, but otherwise there is nothing in common [21:16] Mirv: I'll boot with mem=1G so we'll see what happens [21:24] jbarnes, will check that next time [21:31] I might just have seen it too [21:31] I was idle though after a resume [21:31] no more interrupts [21:31] I wonder if pci=nomsi will help [21:32] also the render clock gating reg looks busted [21:37] mdz-mini: also at some point you'll want to test the mesa upload I just did, to see if your freeze is one that is fixed by dropping this patch 103 [21:37] I think it's still in the approval queue atm [21:38] hasn't frozen yet but it rendering very slow [21:39] came back to normal after a while [21:39] mdz-mini: your last reg dump was from after the hang right? [21:39] jbarnes, correct [21:39] mdz-mini: does the slowness increase over time or is it constantly slow? [21:39] bryce, it gow slow and then nirmal again [21:39] got [21:40] jbarnes, I ran the reg dumper twice, that was the second run in cast that matters [21:40] ok [21:40] shouldn't matter [21:40] this mini 9 keyboard is awful [21:43] * bryce is curious if the mini 12 kbd is better [21:45] I wonder if the vt switch on suspend/resume is a factor [21:45] hmmm [21:45] mdz-mini: could be... if you can reproduce it across vt switch rather than suspend/resume it would mean the bug probably isn't due to lost chip state [21:46] I ran my repro script for 10 minutes without a crash [21:46] then suspended and resumed [21:46] ran it again [21:46] and it crashed after 10 seconds [21:47] backtrace the same as last time [21:47] no i915 interrupts [21:48] jbarnes, anything else I should look at? next I'll reboot and try with a vt switch [21:48] does grep i915 /proc/interrupt show that it's MSI [21:48] 2295: 449673 415505 PCI-MSI-edge i915@pci:0000:00:02.0 [21:48] ok yeah try with vt switch [21:50] mdz-mini: what do you do exactly to trigger it? [21:50] seb128, I'll post the script [21:50] I've tried with video playing, glxgear, workspace switching, alt-tab, suspend resume, no such issue there [21:51] same PCI-MSI-edge on my config [21:51] mdz-mini: thanks [21:51] it just start some apps and switches workspaces [21:51] starts [21:51] ok, I guess there is something else than the video chipset needed there [21:52] I've been using this box full day for the week and never ran into the issue, so I don't think those actions will trigger it now [21:54] jbarnes, vt switch did not seem to trigger it, tried twice [21:55] suspend/resume seemed to do it [21:55] ok [21:55] care to try pci=nomsi [21:55] btw what was the irq count on the last hagn? [21:55] hgn? [21:55] hang [21:55] 2295: 52909 53155 PCI-MSI-edge i915@pci:0000:00:02.0 [21:56] I'm going to add a suspend to the script, confirm that works after a warm boot, then if it's reliable i'll try nomsi [21:56] sounds good [22:10] no joy [22:11] nomsi didn't help? [22:11] no, reproducer isn't reliable enough yet to test [22:11] yuck [22:11] I'm putting together a kernel patch to give us some additional debug info too [22:12] ok [22:13] btw, the 2.6.30-rc2 kernel is at http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc2/ [22:13] has anyone been able to reproduce with a more recent kernel? [22:13] (I'd love to chunk that into a proper ppa if anyone has a clue on how to do that) [22:19] bryce, what's stopping you from just uploading it? [22:20] I'm completely failing to reproduce anymore [22:20] no source package for mailine builds [22:20] +n [22:21] hmm, ask the kernel team. surely they generate one and just don't publish it yet [22:22] heisenfreeze [22:23] reproducibility is inversely proportionate to the availability of means to debug [22:28] * albert23 has the compiz freeze with 2.6.30-rc2 [22:29] intel_reg_dump: http://paste.ubuntu.com/153058/ [22:29] intel_gpu_dump that is [22:30] just got it again [22:30] after some random number of tries with the script [22:31] hrm, this intel-gpu-tools package appears to need libdrm 2.4.6... >just< newer than we have in jaunty [22:32]