[03:36] wow - http://zrusin.blogspot.com/2011/04/apitrace.html [03:50] http://sarvatt.com/downloads/glxgears.trace that look screwed up on anyone elses system when you replay it? been meaning to report this bug on gen6 intel since april 12th's mesa checkout and if that works that'll help a crapload describing it [04:15] Sarvatt: Yeah. I was looking at that and thinking “that's a high priority for Oneiric packaging” :) [04:15] Also, I've just taken delivery of a Dell Ultrasharp 24" monitory. [04:16] Dear lord, 24" monitors are big. I'm glad I didn't go for the 27" :( [04:16] :) [04:17] know any simple packages using cmake by any chance? :P [04:17] planning on packaging it up tomorrow [04:18] Compiz does. [04:18] That's not exactly simple, but hey! Neither's cmake! [04:19] oh thats a lot easier than i thought it'd be [04:30] Dear kernel build: FASTER! [04:38] RAOF: want me to build you one? takes 10 minutes or so [04:38] Yes please. [04:38] what ya need? [04:39] i386, bitte. [04:39] * RAOF builds a source package. [04:39] wonder if this can trace unity, apitrace is falling over on a few more complex things i've run so far - warning: unsupported call glSecondaryColorPointerEXT [04:40] have a patch to apply to the natty or oneiric kernels or are ya doing something more complex? [04:42] I want to test my patch; it should work, but who knows :) [04:42] Untested code is broken! [04:43] its easier if i just build it from ubuntu git with your patch applied if thats ok [04:43] I haven't actually got a patch as such yet, although I could generate it from git if that's easier for you. [04:43] natty or oneiric? [04:43] natty. [04:43] yeah just shoot me the git diff [04:43] Is there an oneiric kernel? [04:44] yep, not published anywhere yet though [04:45] http://cooperteam.net/patchme.patch [04:45] Applies to both natty and oneiric, actually, assuming oneiric is 2.6.39-based. [04:46] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-oneiric.git;a=summary [04:47] natty i386 generic or generic-pae? [04:47] generic [04:47] also do you need headers? [04:47] Nope. [04:47] okie building now [04:47] It only touches drm, and will be tested on a desktop. [04:47] Ta muchly. [04:48] I'll build me a kickarse desktop system soon; I think I want to wait for the z68 chipset first. [04:48] good call :) [04:58] almost done, building the deb now [04:59] What system's that building on? [04:59] * RAOF would *love* a 10 minute kernel build time. [05:00] http://sarvatt.com/downloads/cpuinfo.txt [05:01] http://kernel.ubuntu.com/~sarvatt/raof/ [05:01] Is that a dual-socket quad-core xeon setup? [05:02] real 12m52.920s [05:02] user 115m50.160s [05:02] sys 15m38.780s [05:05] 4 sockets x 8 core cpu with HT :) [05:19] Woot. Looks like that works as expected. [05:19] (IE: not hanging in poll() ☺) [05:20] * RAOF gives it a couple more minutes of dpms cycling. [05:24] awesome, you mean i'll be able to close the lid in a unity session again without having to restart unity from a VT 10% of the time? :P [05:24] * Sarvatt installs [05:24] Yes. [05:24] This is exactly that bug :) [05:31] awesome, it does look to be fixed [05:32] Excellent. [05:33] now if only I didn't have to reenable semaphores on sandybridge to get rid of [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 392605, at 392605], missed IRQ? under compiz unity would be perfect :) [05:34] oh besides the multi monitor bustage === yofel_ is now known as yofel === soreau_ is now known as soreau [18:48] bryceh: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-o-xorg-ubuntu-x-team-huddle did you see when it was scheduled? :) [18:48] monday at noon [18:49] haha [18:52] should just rename it the "create new articles for phoronix to post session" [18:55] hah [18:55] let's play a gag and talk about switching to i915g and wayland entirely for 11.10 [18:57] lol [18:58] Sarvatt: I've seen people claim that earlier already anyway ;-) [18:58] at least the wayland part... [19:14] [ 5.403] [19:14] X.Org X Server 1.10.1 [19:14] why did I not switch to SSD earlier.. [19:27] Sarvatt, yeah the automatic scheduler at work probably [19:50] sarvyou know of any special problem with jockey/nvidia if the user is using the pae kernel? [19:50] Sarvatt, you know of any special problem with jockey/nvidia if the user is using the pae kernel? [19:50] yeah if they only have linux-headers-generic installed they wont get automatic generic-pae header updates [19:51] you need linux-headers-foo-generic-pae instead of linux-headers-foo-generic [19:52] but it's not done automatically [19:52] only if they installed with >4gb ram, and while plugged into the net so it automatically installed the generic-pae kernel, if they did it after the fact they need to install linux-headers-generic-pae too [19:53] really annoying :( [19:53] would be nice if we just switched generic to PAE next cycle IMO :) [19:54] pae would still work as a standard i386 kernel on systems with <4gb right? i mean it's not going to constantly lock up or anything [19:55] yeah its just a small performance penalty and intel had some problems with it back when we were first going to do that (I think it was in .30?). I think phoronix even did some benchmarks showing the differences recently [19:56] http://www.phoronix.com/scan.php?page=article&item=ubuntu_natty_pae64&num=1 [19:56] .30 is quite a while ago [20:01] err he tested machines with 4gb ram or more in those benchmarks, nevermind ignore that article I linked :) [20:02] bjsnider: it's not going to work on cpus that don't support pae [20:02] Sarvatt: fwiw i think the plan for debian is to have a 486 flavour, 686-pae and amd64. no 686/smp without pae anymore. [20:03] jcristau, wouldn't work meaning it would just panic and not even boot? [20:05] probably. [20:05] pretty sure since we are i686 only !PAE isn't an option and that was why it was being considered, will be sure to bring it up at UDS [20:05] there's probably a geode that'll throw a wrench in that [20:07] there are !pae 686 cpus, apparently. pentium m, via c3 nehemiah, geode lx, from the debian-kernel thread. [20:07] pentium m? oh wow [20:09] http://lists.debian.org/debian-kernel/2011/02/msg00246.html [20:12] uptime [20:12] oops :) [21:17] yeah my "new" glorious sis671 laptop has a pentium-m.. [21:17] lucky you. [21:18] thinkpad t23 too [21:19] tjaalton: which pentium m though? most pentium m's supported it.. [21:19] then again, SIS, probably one of the first ones :) [21:19] Sarvatt: hmm, could be a newer one [21:19] it's only 4y old [21:19] the thinkpad is ~9yo [21:30] but doesn't the nx-emulation cover those? [21:34] guess i'll need to install the pae-kernel on the t23 to see [21:41] tjaalton, every sis based xp system i've worked on is unable to smoothly draw a window being dragged across a screen [21:45] bjsnider: well I didn't buy it because of trail blazing performance :) [21:45] that's good because it's not much of an improvement over the sight of a blank screen [21:47] got it a month ago for testing the new code, though i've yet to actually test it [21:49] tjaalton: i've got a sis 741GX/sempron socket 754 combo you can have if you want some more trash :) [21:52] oh its a sis 760gx [21:53] eww [21:54] darn wifi kill switch on this e6420 is waaay too easy to hit === soreau_ is now known as soreau [22:37] [ 0.000000] Notice: NX (Execute Disable) protection missing in CPU! [22:37] [ 0.000000] NX (Execute Disable) protection: approximated by x86 segment limits [22:37] so yeah, pae-kernel works just fine on pentium-m [22:38] on the t23 === soreau__ is now known as soreau