[00:46] poke poke [05:11] oh ya, and some day I'll put a radeon card back into a computer and check if I can still reproduce bug #174427, I promise :p [05:11] Launchpad bug 174427 in xserver-xorg-video-ati "[RV280 9250] [AGP] Tremulous causes X server crash (signal 11) at depth 16" [Medium,Invalid] https://launchpad.net/bugs/174427 [07:37] cwillu: For a more general purpose message, maybe: '''Bugs can have similar symptoms but different root causes. Check that you have the same chipset _before_ commenting (lspci |grep VGA). Upstream has a one-person-one-issue policy, so if you're not 100% certain you have the same issue, your issue won't get examined if you don't report it as a new bug.''' [07:38] (sorry for late reply, I was off work today and it was nice out so mostly worked on the yard and on some shop projects.) === seb128_ is now known as seb128 [11:46] what sets DPMS settings these days? [11:47] I just applied some updates and xset is now showing that my LCD will DPMS-Off after 60 seconds of inactivity. Pretty sure it wasn't like that before, and I expect it'll go away if I bounce X, I'm just curious what touches that stuff these days [11:54] gnome-power-manager [11:55] ah, that crashed during the upgrade :) [11:55] heh [11:55] probably hal restarting [12:09] gods how I hate -intel [12:15] bryce: 277 open bugs :P [12:15] tjaalton: indeed [12:15] all time high on all the team packages [12:15] I think [12:15] lrm doesn't count [12:15] think you're right [12:16] -intel sucks [12:19] enough for one day... night. [12:19] night :) [22:10] patch 116_865g_disable_dri.patch seems a bit unfortunate, given freedesktop bug 21060 [22:10] Freedesktop bug 21060 in Driver/intel "Crash in drm_intel_gem_bo_start_gtt_access with XV if DRI disabled" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=21060 [22:11] and we have crash reports for both 845 and 865 [22:11] (upstream changed the title from XV with large virtual display into XV if DRI disabled) [22:12] hi albert23: [22:12] hi bryce [22:12] funny you should mention this; I just happen to have started looking into all the Xv crash issues [22:13] I went looking for totem crashes :-) [22:13] I agree disabling dri on 865 is unfortunate, but it seems the system doesn't even boot up without that [22:13] so, in my view, playing videos successfully is a secondary issue to that [22:14] well, we can fix the X crash [22:14] and playing video may still be possible without XV [22:14] exactly. also, we're getting a spate of reports of Xv crashes beyond just 865 [22:14] That worked with the large virtual display [22:14] I suspect the crashes are unrelated to whatever is requiring dri disabled on 865 [22:15] albert23: give me any ideas, insights, or data you've uncovered. I'm still just trying to digest it all [22:15] what we really need are full backtraces, and so far none of the bug reports have one. still looking though. [22:15] 347527 has a partial backtrace but it's not enough [22:16] I don't have any 8xx [22:17] I wonder if bug 304871 could be fixed by disabling gem [22:17] Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/304871/+text) [22:18] the "Couldn't bind memory for BO front buffer" problem [22:18] I wondered about that [22:18] given how late we are, and how intricate that chunk of code is, it makes me a bit uncomfortable to think about [22:19] So adding the module option from 349992 would be interesting [22:20] 347527 has " Failed to pin xv buffer" which I found only in one place in -intel [22:21] so that crash we can fix as well [22:22] albert23: how confident are you in your patch for fdo #21060? [22:24] I got that idea because I had seen the combination of the unreference and the pointer=NULL on many other places in the code [22:25] it sounds appropriate to me. wish we had some feedback from upstream on it [22:25] It's assigned to anholt now [22:26] albert23: what does Gordon's last comment on that bug mean? [22:26] I think that explains why he changed the title of the bug [22:27] ohh [22:29] ok, so if I understand correctly, having DRI disabled triggers a code path that causes this bug, and if your virtual frame buffer is set large, that causes DRI to be disabled. [22:29] intriguing [22:29] That's how I understand it as well [22:30] And slangaseks log showed DRI was indeed disabled for him [22:30] ok, suddenly pieces fall into place :-) [22:31] * bryce studies further [22:41] albert23: notice the patch on http://lists.freedesktop.org/archives/intel-gfx/2009-February/001426.html touches the code but still has the unref problem [22:43] that added a condition to the code. And guess what you see in the first half of the condition? [22:43] drm_intel_bo_unreference(pPriv->buf); followed by pPriv->buf = NULL; [22:44] indeed [22:44] but why did they still omit it in the second stanza? hmm [22:45] it sounds like on bug 347527 that it's the inverse of 354688 - crashes *unless* DRI is disabled [22:45] Launchpad bug 347527 in xserver-xorg-video-intel "[830m] mplayer appears to crash X unless DRI is disabled" [Undecided,Incomplete] https://launchpad.net/bugs/347527 [22:49] yeah, that's what the title says. But I don't see evidence DRI was enabled in the log [22:50] seems to use software rendering? 4.130567] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [22:51] [ 2.236645] (**) intel(0): Option "NoDRI" [22:55] bryce: so he has a log with DRI disabled, and containing the crash. That doesn't match the title? [22:57] albert23: yep [22:57] * bryce fixifies title [22:58] ahhh I understand now. Boy I'm slow today [22:59] he has been having unrelated problems (X freezes) that drove him to disable DRI, and now is getting video playback crashes [22:59] so that fits with our hypothesis [22:59] Ahh, you are still faster then me [23:08] 351869 is another dupe [23:09] kewlness, so all the bugs I've looked at so far have either had DRI off for some reason, or was a 945 with virtual buffer > 2048 [23:09] * bryce scans for more dupes [23:10] 352760 [23:13] heya jbarnes [23:13] bryce: hi [23:13] I couldn't reproduce fdo #20739 with current bits or 2.6.1 + 2.6.29 [23:13] trying with jaunty now (my upgrade just finished) [23:13] jbarnes: I think we got a stranglehold on the Xv crash bug. albert23 has a patch that looks like it may solve it - http://bugzilla.freedesktop.org/show_bug.cgi?id=21060 [23:13] Freedesktop bug 21060 in Driver/intel "Crash in drm_intel_gem_bo_start_gtt_access with XV if DRI disabled" [Normal,New] [23:13] bryce: which versions of xf86-video-intel, mesa & kernel is jaunty shipping with? [23:13] seems to be a code path triggered when DRI is off for whatever reason [23:14] bryce: yeah the fix for 21060 looks good [23:14] { 2.6.3, 7.4, 2.6.28+backports } [23:14] any gem fixes backported? [23:15] or are you waiting for me to tell you which ones? :) [23:15] possibly not enough ;-) [23:15] yes please :-) [23:15] some gem stuff is backported for the kernel [23:15] I'm not directly involved in that so don't know the exact details [23:15] there were so many changes... [23:16] what's Martin Pitt's irc nick? [23:16] we're pretty late in the cycle for kernel changes now, so I think the kernel team would be interested only in absolutely critical fixes [23:16] pitti [23:17] right, hopefully a hang fix would qualify [23:17] yep, especially if it affects pitti [23:17] jbarnes: hey btw are any of the register docs public for any of the 8xx chipsets? [23:17] I guess he's not around... is he on the kernel team? [23:18] bryce: not yet... hopefully after the g4x stuff gets released we'll be able to do 915/945 and 8xx [23:18] probably in bed (based in germany). He's the desktop technical lead, so not kernel but pulls lots of weight [23:19] ok cool [23:19] I've got a couple of bugs from him, I'll try chatting with him tomorrow [23:19] aha crashed it w/the jaunty kernel :) [23:20] hm maybe I mean :/ [23:22] ah seems better with 2.6.3 [23:22] jbarnes: regarding the performance issue on intel, I did up a page to help folks troubleshooting such problems - https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance [23:23] I'd love to say, "The reason EXA performance regressed from 2.5 to 2.6 is ..." but I'm clueless [23:23] * jbarnes looks [23:24] bryce: EXA uses GEM too... in fact they share render accel code in *_render.c [23:25] ok [23:28] the UxaTesting page looks interesting... some of the "worse" reports seem unrelated/tangential (like video tearing or 3d perf regression) [23:29] dri2 has lower performance in some cases, mainly due to the tiling regression (which is fixed in 2.6.29) and some additional blit overhead in some cases [23:31] a lot of the reports on that page are on 2.6.1 btw. I neglected to direct people to indicate their driver version [23:31] looking at the wiki changelog, it seems we're getting fewer "worse" reports now, but still quite a few "mixed" [23:31] 2.6.3 was *much* better, uxa-wise [23:32] * bryce nods [23:32] there's also the memory leak in fdo 20704 which is pretty much fixed now [23:32] we do still have a ton of bugs open for issues when UXA is enabled. I've encouraged people to forward them upstream as well, so hopefully you've been seeing an influx of testers [23:32] but again that's a dri2 issue rather than uxa [23:33] yeah we've been working solely on bug fixing for the past few weeks [23:35] kewl [23:38] so one of the big perf issues people found when going from dri1 -> dri2 is that tiled rendering got disabled [23:38] you might add that to the uxa section... it's fixed in 2.6.29 and in the 2.7 driver but it was a pretty huge regression on some 945 platforms [23:39] jbarnes: that also happens with EXA? [23:39] ok [23:39] albert23: what the perf regression? it should only affect dri2 [23:39] performance with 945 and exa is still very poor (dual channel memory) [23:39] dri2 can't be enabled with exa [23:39] ah that could be a bigger gem regression [23:39] and I get it fixed by disabling gem [23:40] anholt has been working on a fix for the daul channel memory problem, the so-called "a17 swizzle" bug [23:41] albert23: how do you disable GEM? [23:42] kees: I patched the intel driver [23:42] haha [23:43] albert23: got the patch? I could at least link to it from the performance page for folks to try [23:43] bryce: that's the one we discussed last week [23:43] albert23: look for "drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU." on the dri-devel mailing list [23:44] albert23: right, my brain is swiss cheese [23:44] kees: http://paste.ubuntu.com/142337/ [23:45] you need to switch of gem and add a second patch (accepted upstream) [23:46] bryce: so those two issues (the tiled rendering/fence reg one and the a17 one) are probably worth adding to that page for your bleeding edge users [23:46] description for the tiled rendering one can be found in my message to intel-gfx, subject "[RFC] support tiled rendering on pre-965 chips" [23:48] jbarnes: thanks, found it [23:49] jbarnes: ok thanks [23:50] albert23: please reply with testing results if you get a chance [23:50] albert23: to eric and dri-devel I mean [23:51] jbarnes: the patch is for kernel 2.6.29 I suppose? [23:51] yeah probably against eric's drm-intel-next branch [23:51] jbarnes, what is "a17"? I saw a bug report on that but don't know what it means. Is it just some register address? [23:52] OK, I will give it a try later this week [23:52] hmm maybe I've asked this question before [23:52] bryce: it refers to a memory addressing mode [23:52] bryce: our gpu & memory controller are on the same chip [23:52] and there are all sorts of weird addressing modes they use in combination with the cpu to increase performance [23:53] a17 is one of the bits ("address bit 17") that gets set or cleared in certain dual channel configs [23:54] normally it's invisible, but if a page of graphics memory gets swapped out and then back in at a different address, the a17 setting for the new page might be different [23:54] and until Eric's patch we didn't track that, so we just had to disable tiling (and thus any a17 funkiness) altogether [23:57] * bryce updates https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance [23:58] thanks jesse, hopefully I didn't butcher the explanation too badly [23:59] * jbarnes checks