[00:46] <cwillu> poke poke
[05:11] <cwillu> 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
[07:37] <bryce> 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] <bryce> (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.)
[11:46] <Ng> what sets DPMS settings these days?
[11:47] <Ng> 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] <tjaalton> gnome-power-manager
[11:55] <Ng> ah, that crashed during the upgrade :)
[11:55] <tjaalton> heh
[11:55] <Ng> probably hal restarting
[12:09] <bryce> gods how I hate -intel
[12:15] <tjaalton> bryce: 277 open bugs :P
[12:15] <bryce> tjaalton: indeed
[12:15] <tjaalton> all time high on all the team packages
[12:15] <tjaalton> I think
[12:15] <tjaalton> lrm doesn't count
[12:15] <bryce> think you're right
[12:16] <bryce> -intel sucks
[12:19] <bryce> enough for one day...  night.
[12:19] <tjaalton> night :)
[22:10] <albert23> patch 116_865g_disable_dri.patch seems a bit unfortunate, given freedesktop bug 21060
[22:11] <albert23> and we have crash reports for both 845 and 865
[22:11] <albert23> (upstream changed the title from XV with large virtual display into XV if DRI disabled)
[22:12] <bryce> hi albert23: 
[22:12] <albert23> hi bryce
[22:12] <bryce> funny you should mention this; I just happen to have started looking into all the Xv crash issues
[22:13] <albert23> I went looking for totem crashes :-)
[22:13] <bryce> I agree disabling dri on 865 is unfortunate, but it seems the system doesn't even boot up without that
[22:13] <bryce> so, in my view, playing videos successfully is a secondary issue to that
[22:14] <albert23> well, we can fix the X crash
[22:14] <albert23> and playing video may still be possible without XV
[22:14] <bryce> exactly.  also, we're getting a spate of reports of Xv crashes beyond just 865
[22:14] <albert23> That worked with the large virtual display
[22:14] <bryce> I suspect the crashes are unrelated to whatever is requiring dri disabled on 865
[22:15] <bryce> albert23: give me any ideas, insights, or data you've uncovered.  I'm still just trying to digest it all
[22:15] <bryce> what we really need are full backtraces, and so far none of the bug reports have one.  still looking though.
[22:15] <bryce> 347527 has a partial backtrace but it's not enough
[22:16] <albert23> I don't have any 8xx
[22:17] <albert23> I wonder if bug 304871 could be fixed by disabling gem
[22:18] <albert23> the "Couldn't bind memory for BO front buffer" problem
[22:18] <bryce> I wondered about that
[22:18] <bryce> given how late we are, and how intricate that chunk of code is, it makes me a bit uncomfortable to think about
[22:19] <albert23> So adding the module option from 349992 would be interesting
[22:20] <albert23> 347527 has " Failed to pin xv buffer" which I found only in one place in -intel
[22:21] <albert23> so that crash we can fix as well
[22:22] <bryce> albert23: how confident are you in your patch for fdo #21060?
[22:24] <albert23> 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] <bryce> it sounds appropriate to me.  wish we had some feedback from upstream on it
[22:25] <albert23> It's assigned to anholt now
[22:26] <bryce> albert23: what does Gordon's last comment on that bug mean?
[22:26] <albert23> I think that explains why he changed the title of the bug
[22:27] <bryce> ohh
[22:29] <bryce> 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] <bryce> intriguing
[22:29] <albert23> That's how I understand it as well
[22:30] <albert23> And slangaseks log showed DRI was indeed disabled for him
[22:30] <bryce> ok, suddenly pieces fall into place :-)
[22:31]  * bryce studies further
[22:41] <bryce> 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] <albert23> that added a condition to the code. And guess what you see in the first half of the condition?
[22:43] <albert23> drm_intel_bo_unreference(pPriv->buf); followed by pPriv->buf = NULL;
[22:44] <bryce> indeed
[22:44] <bryce> but why did they still omit it in the second stanza?  hmm
[22:45] <bryce> it sounds like on bug 347527 that it's the inverse of 354688 - crashes *unless* DRI is disabled
[22:49] <albert23> yeah, that's what the title says. But I don't see evidence DRI was enabled in the log
[22:50] <albert23> seems to use software rendering? 4.130567] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[22:51] <bryce> [    2.236645] (**) intel(0): Option "NoDRI"
[22:55] <albert23> bryce: so he has a log with DRI disabled, and containing the crash. That doesn't match the title?
[22:57] <bryce> albert23: yep
[22:57]  * bryce fixifies title
[22:58] <bryce> ahhh I understand now.  Boy I'm slow today
[22:59] <bryce> he has been having unrelated problems (X freezes) that drove him to disable DRI, and now is getting video playback crashes
[22:59] <bryce> so that fits with our hypothesis
[22:59] <albert23> Ahh, you are still faster then me
[23:08] <bryce> 351869 is another dupe
[23:09] <bryce> 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] <albert23> 352760
[23:13] <bryce> heya jbarnes
[23:13] <jbarnes> bryce: hi
[23:13] <jbarnes> I couldn't reproduce fdo #20739 with current bits or 2.6.1 + 2.6.29
[23:13] <jbarnes> trying with jaunty now (my upgrade just finished)
[23:13] <bryce> 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] <jbarnes> bryce: which versions of xf86-video-intel, mesa & kernel is jaunty shipping with?
[23:13] <bryce> seems to be a code path triggered when DRI is off for whatever reason
[23:14] <jbarnes> bryce: yeah the fix for 21060 looks good
[23:14] <bryce> { 2.6.3, 7.4, 2.6.28+backports }
[23:14] <jbarnes> any gem fixes backported?
[23:15] <jbarnes> or are you waiting for me to tell you which ones? :)
[23:15] <bryce> possibly not enough ;-)
[23:15] <bryce> yes please :-)
[23:15] <bryce> some gem stuff is backported for the kernel
[23:15] <bryce> I'm not directly involved in that so don't know the exact details
[23:15] <jbarnes> there were so many changes...
[23:16] <jbarnes> what's Martin Pitt's irc nick?
[23:16] <bryce> 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] <bryce> pitti
[23:17] <jbarnes> right, hopefully a hang fix would qualify
[23:17] <bryce> yep, especially if it affects pitti
[23:17] <bryce> jbarnes: hey btw are any of the register docs public for any of the 8xx chipsets?
[23:17] <jbarnes> I guess he's not around... is he on the kernel team?
[23:18] <jbarnes> bryce: not yet... hopefully after the g4x stuff gets released we'll be able to do 915/945 and 8xx
[23:18] <bryce> probably in bed (based in germany).  He's the desktop technical lead, so not kernel but pulls lots of weight
[23:19] <jbarnes> ok cool
[23:19] <jbarnes> I've got a couple of bugs from him, I'll try chatting with him tomorrow
[23:19] <jbarnes> aha crashed it w/the jaunty kernel :)
[23:20] <jbarnes> hm maybe I mean :/
[23:22] <jbarnes> ah seems better with 2.6.3
[23:22] <bryce> 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] <bryce> 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] <jbarnes> bryce: EXA uses GEM too... in fact they share render accel code in *_render.c
[23:25] <bryce> ok
[23:28] <jbarnes> the UxaTesting page looks interesting... some of the "worse" reports seem unrelated/tangential (like video tearing or 3d perf regression)
[23:29] <jbarnes> 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] <bryce> 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] <bryce> looking at the wiki changelog, it seems we're getting fewer "worse" reports now, but still quite a few "mixed"
[23:31] <jbarnes> 2.6.3 was *much* better, uxa-wise
[23:32]  * bryce nods
[23:32] <jbarnes> there's also the memory leak in fdo 20704 which is pretty much fixed now
[23:32] <bryce> 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] <jbarnes> but again that's a dri2 issue rather than uxa
[23:33] <jbarnes> yeah we've been working solely on bug fixing for the past few weeks
[23:35] <bryce> kewl
[23:38] <jbarnes> so one of the big perf issues people found when going from dri1 -> dri2 is that tiled rendering got disabled
[23:38] <jbarnes> 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] <albert23> jbarnes: that also happens with EXA?
[23:39] <bryce> ok
[23:39] <jbarnes> albert23: what the perf regression?  it should only affect dri2
[23:39] <albert23> performance with 945 and exa is still very poor (dual channel memory)
[23:39] <jbarnes> dri2 can't be enabled with exa
[23:39] <jbarnes> ah that could be a bigger gem regression
[23:39] <albert23> and I get it fixed by disabling gem
[23:40] <jbarnes> anholt has been working on a fix for the daul channel memory problem, the so-called "a17 swizzle" bug
[23:41] <kees> albert23: how do you disable GEM?
[23:42] <albert23> kees: I patched the intel driver
[23:42] <kees> haha
[23:43] <bryce> albert23: got the patch?  I could at least link to it from the performance page for folks to try
[23:43] <albert23> bryce: that's the one we discussed last week
[23:43] <jbarnes> albert23: look for "drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU." on the dri-devel mailing list
[23:44] <bryce> albert23: right, my brain is swiss cheese 
[23:44] <albert23> kees: http://paste.ubuntu.com/142337/
[23:45] <albert23> you need to switch of gem and add a second patch (accepted upstream)
[23:46] <jbarnes> 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] <jbarnes> 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] <albert23> jbarnes: thanks, found it
[23:49] <bryce> jbarnes: ok thanks
[23:50] <jbarnes> albert23: please reply with testing results if you get a chance
[23:50] <jbarnes> albert23: to eric and dri-devel I mean
[23:51] <albert23> jbarnes: the patch is for kernel 2.6.29 I suppose?
[23:51] <jbarnes> yeah probably against eric's drm-intel-next branch
[23:51] <bryce> 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] <albert23> OK, I will give it a try later this week
[23:52] <bryce> hmm maybe I've asked this question before
[23:52] <jbarnes> bryce: it refers to a memory addressing mode
[23:52] <jbarnes> bryce: our gpu & memory controller are on the same chip
[23:52] <jbarnes> and there are all sorts of weird addressing modes they use in combination with the cpu to increase performance
[23:53] <jbarnes> a17 is one of the bits ("address bit 17") that gets set or cleared in certain dual channel configs
[23:54] <jbarnes> 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] <jbarnes> 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] <bryce> thanks jesse, hopefully I didn't butcher the explanation too badly
[23:59]  * jbarnes checks