=== fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [11:51] Heya. Mark has talked many times about "ultrasmooth" graphics. This is achieved with a low-jitter kernel. [11:51] Please see: http://ovekarlsen.com/Blog/turning-ubuntu-12-04-into-a-professional-low-jitter-os/ [11:51] I can answer any questions. [12:19] Low-jitter reduces interrputs in the datastreams, giving continuous graphics and audio, that is optimal for a multimedia computer OS. [12:20] For instance Doom 3 which is a very jitter sensitive game, that Carmack not long ago stated was taxing even on modern computers, runs with accurate 72fps. [12:20] This also on a core 2 duo, and GTX 280. [12:20] Doom 3 does three passes pr Open GL frame. [12:21] interrupts :) [12:32] why did you change your name? [12:34] and only considering the kernel as a source of jitter is going to majorly miss all the real issues === fmasi is now known as fmasi_afk === fmasi_afk is now known as fmasi [13:04] ohsix: It is tried and tested, there is no other real issues. [13:14] apw, suppose we oughtta do a signed package for Saucy LTS ? [13:15] * henrix -> lunch [13:18] rtg, hmm, i suppose we might indeed [13:18] apw, are you still the expert there ? [13:19] rtg, yeah i'll take the action indeed [13:23] smb: hi [13:24] arges, maybe... :) [13:24] : ) [13:24] smb: bug 1007082 [13:24] Launchpad bug 1007082 in linux (Ubuntu) "BUG: Bad page state in process node pfn:8e9d9" [Medium,Incomplete] https://launchpad.net/bugs/1007082 [14:22] Anyone know how I can start to figure out why my laptop is a lot hotter on saucy? [14:39] jpds, it is sitting on your lap ? [14:40] apw: Partially, but the fan is spinning a lot more than what I'm use to. [14:40] maybe install a raring kernel and see if that changes things [14:40] jpds, shame you didn't upgrade 3m ago :( === gfrog_ is now known as gfrog [15:51] how does dmesg get the timestamps used to mark entries? [15:51] is it possible to get that number at any point? [15:52] this number '[ 9231.618344]' [15:52] which i guess is seconds after boot [16:12] tjaalton, hey, so regarding those in-raring-but-not-in-3.8-stable haswell commits . . . I'd be happy to take the two from upstream in 3.8-stable, if you were to request that [16:12] tjaalton, that would be raring's e8c14411e539718 and 0009bd009e9ec8b [16:14] kamal: yeah, do you need a formal request? [16:15] tjaalton, yes please... an email to me with cc: stable@vger.kernel.org . The upstream commits to request are: [16:15] commit 21ad833075801a7cd81b5ef1604ffc6c600e5ff9 upstream. [16:15] commit 7b9f35a6dd72f89452c58bbdbaf063027bf857ec upstream. [16:16] ok, I'll cc the authors too so they can yell 'no!' if they want :) [16:16] tjaalton, sure sounds good (I'll also do that when I actually queue up the patches) [16:16] not that I think they should [16:19] i'm working on backporting power well changes for haswell, it doesn't support hdmi/dp audio on 3.8 currently [16:20] but getting that in stable might be asking a bit too much, currently at five patches and it's not fully there yet [16:20] tjaalton, um . . . does that relate to 2124b72e6283c4e84a55e71077fee91793f4c801 (which I'm about to queue for 3.8-stable, as requested by Shuduo Sang) [16:20] kamal: yes, it needs the other four patches [16:20] tjaalton: 212b72e drm/i915: don't disable the power well yet [16:21] or at least it applies cleanly after them [16:21] but it's not enough; after unplugging the cable, the hdmi/dp audio device is still listed on audio properties [16:22] works fine on 3.11 [16:22] and apparently on 3.9-rc5 [16:22] tjaalton, hmm. I backported 212b72e to 3.8 with no fuss at all (didn't apply cleanly, but was an easy/obvious port). I wasn't aware that it needed any other patches, but ... [16:22] huh, ok [16:22] see my email (in kteam@) to Shuduo, asking whether it's really even relevant for 3.8 [16:23] Subject: Re: stable: 2124b72e6283c4e84a55e71077fee91793f4c801 need backport [16:23] tjaalton, . . . . so now I'm confused. [16:23] well, I thought 7f35610cc33cf7ee0797dc684ccc0057742dc12a is just as wanted [16:23] but, we'll see after some testing [16:23] if the one patch is enough then that's good [16:24] I can't find 7f35610cc33cf7ee0797dc684ccc0057742dc12a (which repo?) [16:25] oops, mine :) [16:25] hang on [16:25] fa42e23c1055a4 is better [16:26] so, the bisection showed the proposed patch fixing things, but of course i915 got 265 other commits to the driver since 3.8.. [16:26] tjaalton, well, fwiw fa42e23c1055a4 applies cleanly to my 3.8 tree [16:27] yeah it does [16:28] tjaalton, and I'd take it if requested (and assuming it actually compiles :-) [16:28] the other commits I'm testing with are cb10799c194369633b18, 6b25a88752e8e and d5f21e4072645d0 [16:29] but wth.. now I see that this branch doesn't have 2124b72e6283c, grr [16:30] so I'll just rerun the tests, maybe things work after pulling it [16:31] tjaalton, ok, lmk what you want to do after you sort it all out. fwiw, all three of those ^^ look fine to me also. [16:31] ok cool [16:31] cking, thanks for the answer on dmesg [16:31] since the primary target is the quantal i915_hsw driver they're probably fine there but would be silly not to have them on 3.8/raring too [16:32] especially since it's all haswell anyway [16:32] tjaalton, agreed, plus it makes my life easier for future i915 stable merges [16:33] sure === fmasi is now known as fmasi_afk