[04:13] Now. Does this *still* crash X? Who knows! [04:13] No! Cool! [04:30] Oh, that does :( [04:40] Ensuring X doesn't crash would be more fun if testing didn't mean that X crashed :( [04:43] at least when you find that X doesn't crash, you know you've done something right [04:46] Well, yeha. [04:56] Doesn't make the failure mode any less obnoxious :) [09:15] I'm looking for a sponsor for a tiny mesa upload to fix crashes in clutter apps with multiple stages like Quadrapassel - http://cooperteam.net/Packages/mesa_7.9~git20100924-0ubuntu2.dsc [10:13] RAOF: check [10:15] uploaded [14:15] hi, when I try and watch a movie (vcl or Movie player) xorg crashes it seems and it returns me to the login screen. The only thing funny in Xorg.log.old is "intel(0): drmDropMaster failed: Bad file descriptor." This started happening overnight :/ [14:41] http://ubuntuforums.org/showthread.php?p=9907713#post9907713 describes my issue, if anybody is willing to take a look :) [14:53] andrewaclt: it's because you have drm_kms_helper.poll=N, that only works on a newer kernel and prevents the module from loading on the older one unfortunately [14:54] because the module parameter didn't exist back in 2.6.32 [14:54] I see [14:54] So it's loading the wrong module? [14:55] it's not loading the module at all, if you remove that it should work again [14:55] I see, thanks. [14:55] no problem, sorry for not mentioning that when you were testing the newer kernel [15:02] Sarvatt, Thanks, I'm glad a asked here, otherwise that would of taken me forever to figure out :) [19:59] ugh, need to go through this mess of patches for xorg-server in maverick and see if one of them is the cause of server-1.9-branch failing to pass the tests now - http://launchpadlibrarian.net/56814698/buildlog_ubuntu-maverick-amd64.xorg-server_2:1.9.0%2Bgit20100930%2Bserver-1.9-branch.4d2542a1-0ubuntu0sarvatt_FAILEDTOBUILD.txt.gz [20:00] Sarvatt, hi, what do you think about adding kernel 2.6.36 to edgers? [20:01] would be much appreciated if you want to put it in there [20:02] are amd64 kernels building in PPA's again yet? [20:02] would takes some time to upload it for me, but the current natty kernel runs fine here [20:02] there is a commit which should solve this space issue [20:02] * Sarvatt nods [20:03] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=2a96002816aec5f2dae290d473ee3620090088b0 [20:04] it could get hairy for external module users since they aren't going to bump the ABI till natty opens [20:04] right, hmm [20:05] wont be that long though and its not installed by default unless we do a meta package too anyway [20:07] ok, i will upload it [20:15] hmm maybe http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.9-branch&id=d4ef63f602325a9920dc1cbf64e3969dfa394d5f really did break the xserver tests [20:16] there's a bugzilla about it regressing some stuff [20:17] https://bugs.freedesktop.org/show_bug.cgi?id=30267 [20:17] Freedesktop bug 30267 in Input/Core "openarena mouse faliure since dix: don't create core motion events for non-x/y valuators" [Normal,Reopened] [21:40] hello, which library provides this API - XkbChangeTypesOfKey() ; is it libxkbfile? [21:41] gah! why does something in stock always not work for me :( [21:41] if i use the mainline kernels, i dont have problems with X :( [21:44] achiang: libX11 [21:44] jcristau: thank you. i have a bug with a test case [21:45] jcristau: it's present in lucid and still present in maverick. i haven't gotten around to testing upstream yet, because i haven't figured out how to test the latest upstream [21:46] when did the drm changes land ? was that in .32-16 ? [21:49] vish: yeah but there have been quite a few updates since then with drm bits from .34 and .35 stable even. what's wrong now? [21:49] achiang: that function hasn't changed in years, it's either a server bug or it's not fixed upstream [21:49] achiang: so best to file your bug there imo. [21:49] Sarvatt: remember i had shown a video, of /only/ the guest session flickering? [21:49] jcristau: i don't know much about this actually; i'm passing the bug along for a customer who discovered it. would you like to see the test case? [21:49] its been the same issue since then [21:50] radeon? the new_pll problem? [21:50] yup, thats the one [21:50] achiang: i wouldn't know what to do with it :) [21:50] jcristau: or, i can just file an upstream bug, that's easy enough [21:50] xkb scares me. [21:50] they disabled new_pll on rv515 but i think you had a rv530? [21:50] i have RV515 [21:51] oh maybe i had those backwards, or the proposed kernel with the fix isnt out yet [21:51] well, i'm on maverick :) [21:51] mainline .35.x works? [21:52] they ripped out new_pll completely in .36 afaik [21:52] i was using mainline maverick kernel on a lucid system, but now i'm fully on maverick stock [21:52] and still the same ol issue [21:53] sounds like the fix only got backported to lucid, and will come down from the next .35 stable update, let me make sure [21:54] * vish files a bug again .. [21:54] i think the last one got duped to some other bug with the flickering.. [21:55] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0d9958b18e10d7426d94cc3dd024920a40db3ee2 [21:55] there it is upstream, dont see it in ubuntu/ubuntu-maverick.git [21:57] Sarvatt: should i file the bug in kernel? or in -ati ? [21:57] its in 2.6.35.5 [21:58] vish: it shouldnt even be needed, we'll get it free whenever the kernel can get updated next [21:59] Sarvatt: hehe, i tried waiting for this lucid last time :D , and maverick is here.. [21:59] * vish crosses fingers this time ;) [22:00] i know there's a 2.6.35-23 kernel in a kernel team ppa somewhere.. [22:01] https://edge.launchpad.net/~leannogasawara/+archive/kernel-ppa [22:02] pretty sure thats intended to go in maverick before the release, or on the same day [22:02] cool! [22:03] at least you dont have an rv530, the need the same quirk and dont have it yet :) [22:03] :) [22:05] i need to check the new_pll quirk too! iirc, the last time what it did was delay the problem much longer.. [22:05] * vish tries ppa and makes sure.. ;) [22:42] wow people weren't kidding about the conservative governor being a lot better than ondemand in recent kernels [22:52] Sarvatt: hm, where's a link to that train of thought? [22:53] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-September/012168.html [22:55] Sarvatt: interesting thanks [22:55] it seems more willing to go into higher p-states for shorter periods of time and chrome feels more responsive because of it, of course it could be all in my head :) [22:56] things have been unbearably slow all throughout maverick here [22:56] Sarvatt: but if you read through to the end of the thread, you see this: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-September/012176.html === yofel_ is now known as yofel [23:00] Sarvatt: well, mjg59 says "conservative takes longer to drop back to lower frequencies; So it's just about plausible; Depending on the workload..." [23:27] hey all, I'm testing Maverick and getting frequent X restarts when using the proprietary nvidia drivers, is there value in debugging the issue and filing a bug?