[03:18]  * cwillu pokes bryce with a stick (or anyone else interested in slight display corruption on radeon that goes away with Option "AccelDFS" "false")
[03:18] <cwillu> I'm reading man radeon, and interpreting it to be saying that AccelDFS is only enabled by default for plain old pci cards (not agp).  Is that correct?
[03:18] <cwillu> or is it also enabled for pcie cards?
[03:19] <crdlb> I assume the latter
[03:19] <cwillu> I just started upgrading some machines with PCI 9250 (RV270) cards.
[03:20] <crdlb> apparently, AGP is terrible
[03:20] <cwillu> PCI is just as terrible :p
[03:20] <cwillu> (not talking pcie)
[03:20] <crdlb> I don't mean in the performance sense
[03:20] <cwillu> even plain metacity without composite gets terrible corruption after an hours work or so
[03:20] <cwillu> I don't mean it in that sense either
[03:20] <crdlb> I mean in the number of gray hairs it causes
[03:21] <cwillu> I mean in the amount that glyphs start looking like hieroglyphics rather than latin letters :p
[03:21] <cwillu> gimp under metacity-with-compositing or compiz show immediate corruption when drawing
[03:22] <cwillu> "AccelDFS false" fixes both the uncomposited-corruption-after-an-hour-or-so and the composited corruption in gimp
[03:22] <cwillu> does it make sense that the old pci cards would have the same issue with that hook as an agp card would?
[03:23] <cwillu> and if so, can I suggest that DFS should be disabled by default for pci as well as agp?  (again, I'm not referring to pcie)
[13:21] <mnemo> bryce: I think it would be usful if you tagged the gdm package in such a way that it automatically collected all the usual logs (like xorg.log, dmesg etc) when "ubuntu-bug gdm" bugs are filed
[19:13] <bryce> jbarnes: fresh lead on the X freeze issue
[19:14] <jbarnes> what news?
[19:14] <jbarnes> btw apw: ping
[19:14] <bryce> jbarnes: seems we have a patch in -intel from https://bugs.freedesktop.org/show_bug.cgi?id=19304#c13
[19:14] <jbarnes> bryce: removing it prevents the hangs?
[19:14] <bryce> after reverting that patch, my system has been running the repro.sh script for over an hour without freeze (normally freezes in 10 min)
[19:14] <bryce> yes
[19:15] <jbarnes> ooh that's a good data point
[19:15] <bryce> I'm going to be doing more testing, but this is the first thing that's ever worked with compiz on
[19:15] <jbarnes> btw that particular patch was probably broken
[19:16] <bryce> it looks like the version of the patch we have in ubuntu is an early draft of what you were working on with that bug
[19:16] <jbarnes> the most recent one is https://bugs.freedesktop.org/attachment.cgi?id=25116
[19:16] <jbarnes> but it includes some pipestat writes that shouldn't exist in the 2d driver
[19:16] <jbarnes> bryce: yeah that was just a test hack
[19:17] <bryce> yeah the actual patch we have is one pitti made some mods to, but still based on that early version
[19:17] <jbarnes> https://bugs.freedesktop.org/show_bug.cgi?id=19304 has the latest on that
[19:17] <jbarnes> short story is I still don't have a complete fix for pitti's bug
[19:17] <jbarnes> but I think we've narrowed it down
[19:17] <jbarnes> anyway if that really was the cause, then yay!
[19:19] <bryce> yeah... guess we need a cleaner procedure for handling test hacks vs. proven patches
[19:19] <bryce> http://launchpadlibrarian.net/26039104/109_i830-fifo-watermark-conservative.patch
[19:19] <bryce> that is the actual patch currently included in jaunty
[19:22] <jbarnes> well the most conservative stance would be not to apply anything that isn't already upstream (just like the linux stable rules)
[19:22] <jbarnes> that would have prevented this particular patch from getting applied
[19:22] <jbarnes> since I'm not happy enough to push it yet
[19:24]  * bryce nods
[19:25] <bryce> also, I think I may have reviewed this patch, but I did not upload it
[19:27] <bryce> (normally I'd not upload something I didn't get an ok on from you, that wasn't upstream)
[19:29] <jbarnes> yeah
[19:31] <bryce> jbarnes: does this patch affect only 3D behavior, or is it something that could cause freezes in 2D for users not using compiz?
[19:31] <jbarnes> it could affect any configuration
[19:31] <jbarnes> since it it messes with the way the GPU fetches from RAM
[19:33] <bryce> hmm, two commenters on the bug report still seeing freezes
[19:36] <bryce> although, one reporter is a bit ambiguous, and the other I wonder might have a different freeze
[19:37] <bryce> anyway, I'd done a ton of git bisecting on my box over the weekend so it's not in a very pristine state.  I'll need to get it back to a more stock configuration and do the test a few more times before I can say for certain, but this patch feels like our culprit.
[19:38] <bryce> (fwiw, git bisecting mesa == pain)
[19:41] <jbarnes> cool thanks for the update
[19:42] <jbarnes> and if you see apw can you ping him about the MCHBAR stuff?  he tested those patches and I'm still waiting on his tested-by messages to intel-gfx
[19:42] <jbarnes> (along with the pnp resource code he actually used; he fixed up one of the patches)
[20:04] <bryce> done
 bryce, He [apw] might get back in later. He was somewhere travelling
[20:06] <bryce> jbarnes: ok, confirmed that the user I thought may see the problem with UXA does in fact have the problem with UXA
[20:08] <bryce> (with or without the patch 109 present)
[20:08] <jbarnes> sigh
[20:08] <jbarnes> but you thought that might be a separate bug?
[20:40] <bryce> jbarnes: yeah that's my gut feel
 bryce, yes got distracted.  i used a backport version so i need to send those out with the underlying core allocator range change with my tested stuff on it.  will do that in the am
[20:41] <bryce> jbarnes: I've gone back to stock mesa, and still after >20 min no freeze
[20:41] <bryce> also, fwiw performance seems to be better
[20:42] <mnemo> bryce: im curious... how did you "go back to stock mesa"? what commands did you use?
[20:43] <bryce> just apt-get install mesa-common-dev et al
[20:43] <mnemo> ok so when you bisected mesa you pulled bits into the debian git and installed an actual DEB each time?
[20:43] <bryce> yes
[20:43] <mnemo> ah ok I see
[20:44] <bryce> well, a bit more complicated than that, but yeah I did the testing using debs
[20:44] <bryce> otherwise, I worried it'd make it difficult to get back to a stock config
[20:44] <mnemo> yes I've tried "make install" with mesa and I had to re-roll the whole machine ;o
[20:45] <bryce> ouch
[20:46] <bryce> mnemo: yeah I can imagine 
[20:46] <mnemo> well i'm such a newbie that I wreck my box quite often so I developed a small bash script that re-configures ubuntu just the way I want it with tons of gconftool commands and what not
[20:46] <bryce> oh, that's smart
[20:46] <bryce> yeah I had something like that on one of my psb test boxes that I used to have to reimage regularly
[20:47] <mnemo> anyway, but I was thinking maybe it was possible to do --prefix=/usr/local on mesa autogen.sh and then just delete everything in /usr/local when done but I never tried this and it seems timo also pulls into debian git and then installs a DEB
[20:47] <bryce> jbarnes: oh crap
[20:47] <bryce> jbarnes: I just noticed I had UXA turned on.  No wonder it was faster :-P
[20:48] <mnemo> bryce: one more pretty unreleated question... is it correct that the radeonhd driver is never used in ubuntu unless the user explicitly installs it?
[20:48] <jbarnes> heh
[20:49] <bryce> mnemo: correct
[20:54] <bryce> jbarnes: rats, still freezes
[20:54] <jbarnes> arg
[20:55] <jbarnes> maybe you should just give up and move to uxa/dri2 :)
[20:55] <bryce> in fact, that was eric's only advice :-(
[20:57]  * mnemo looks at the EOL date for EXA in ubuntu ... http://www.markshuttleworth.com/archives/146
[20:57] <mnemo> I guess its mid 2011 for dapper and early 2011 for jaunty
[21:01] <bryce> :-
[21:01] <bryce> +/
[21:02]  * bryce returns to being out of ideas
[21:02] <mnemo> bryce: which bug are you trying to figure out? and what hardware does it repro on?
[21:03] <bryce> bug 359392 on i965
[21:03] <bryce> https://wiki.ubuntu.com/DesktopTeam/i965Users
[21:05] <mnemo> ah right the blacklist bug
[21:06] <bryce> gods I'm sick of this bug
[21:24] <jbarnes> bryce: btw we've been talking about providing a multi-drm master patch for 2.6.28 kernels
[21:24] <jbarnes> bryce: it would allow for acceleration even on secondary servers (e.g. for fast user switching)
[21:26] <bryce> interesting, tell me more?
[21:31] <jbarnes> it's a fairly small kernel patch that allows the 2d drivers to drop their drm master status
[21:31] <jbarnes> which allows a subsequent server start to be a drm master, which means it can initialize all the stuff required for 3d
[21:31] <jbarnes> so no more second class status for secondary servers
[21:31] <jbarnes> they'd all be equal
[21:32] <bryce> ok, so on FUSA, server #1 could drop drm master status, and server #2 could pick it up during the switch?
[21:32] <jbarnes> right
[21:32] <jbarnes> or at startup
[21:32] <bryce> is this unnecessary for 2.6.30, or already present there?
[21:32] <jbarnes> yeah 2.6.29 and 2.6.30 already have support for it
[21:33] <bryce> ok
[21:33] <jbarnes> you'll see messages in the log about setting and dropping master
[21:39] <bryce> jbarnes: https://wiki.ubuntu.com/DesktopTeam/i965Users
[21:39] <bryce> jbarnes: interesting that there seems to be a strong correlation between amd64 use and seeing the freeze
[21:40] <bryce> jbarnes: oddly, I seem to be one of the contrary points
[21:42] <jbarnes> yeah I was curious about that...  seems only one other i386 user can reproduce the problem with the script
[21:43] <bryce> jbarnes: are you 64-bit or 32-bit?
[21:44] <jbarnes> 64 bit
[21:47] <bryce> what's weird is ogasawara has the same model of laptop as me (just more ram I guess) and doesn't see the freezes during ordinary use
[21:49] <jbarnes> have you tried to force a lot of swapping (by running a memory hog or something) to see if that makes it easier to trigger?
[21:49] <seb128> did anybody had the issue using a virtual setting?
[21:49] <seb128> I just noticed that several users said not getting the freeze and having virtual set
[21:49] <seb128> I'm in this case
[21:59] <bryce> I'm testing that theory now; seems to be working
[21:59] <bryce> jbarnes: I don't generally have trouble reproducing it now, using the repro.sh script so haven't tried that.  
[22:00] <bryce> Typically I get the freeze in under 10 min of starting the repro.sh script
[22:00] <jbarnes> oh then instead you could unmounting your swap partition
[22:00] <jbarnes> w/swapoff
[22:00] <jbarnes> and make sure you don't have a swap file
[22:00] <bryce> ok
[22:00] <jbarnes> just in case it's the swapping code that's causing the failure
[22:00] <seb128> jbarnes: "that theory" is the virtual setting one I think, not the swap use one
[22:01] <jbarnes> ah
[22:02] <bryce> ok, hmm seems seb128's theory works on my hw
[22:02] <bryce> jbarnes: any idea why it would work with Virtual 2048 2048 but freeze when setting automatically (to 1280 1280)
[22:02] <seb128> I'm one of those who never had the freeze but I've a virtual setting since jaunty start I think
[22:02] <bryce> seb128: if you remove that, then do you get freezes?
[22:02] <seb128> I tried once to set 2 screens using the xrandr capplet and it did that for me
[22:03] <jbarnes> we might have a bogus check in there that disables certain features with a 2k width on 965
[22:03] <jbarnes> (945 has that limit but 965 is bigger)
[22:03] <seb128> bryce: I tried, I think it becomes way slower in some cases but I didn't get a hang
[22:03]  * bryce tries 2047
[22:04] <bryce> seb128: yeah I notice a performance difference as well
[22:04] <seb128> I'm also one of those guys who never had performances issues in jaunty ;-)
[22:04] <bryce> fwiw, mdz's repro.sh script always triggers the freeze for me within about 15min
[22:04] <seb128> I'm wondering if all that is thanks to the virtual setting ;-)
[22:06] <bryce> if we had to force it to 2048 2048 I would not be sad.  A nice side effect is that it would make the projector use case work better ;-)
[22:06] <seb128> that's still a workaround though
[22:06] <seb128> but maybe it could give some clue on the issue
[22:07] <bryce> at least, it's a better workaround than our current workaround of shutting off compiz entirely
[22:07] <bryce> assuming it works for everyone and doesn't cause some other regression
[22:07] <bryce> ok looks like even 2047 2047 works without freezing
[22:07] <seb128> right
[22:08]  * bryce tries 1280 1280
[22:14] <bryce> yep, froze
[22:14] <bryce> mmm
[22:14]  * bryce tries 1281 1281
[22:14] <jbarnes> what's the diff in your X logs between those two cases?
[22:14]  * bryce looks
[22:15] <bryce> http://pastebin.ubuntu.com/159638/
[22:16] <jbarnes> ok so exa offscreen size changed significantly
[22:16] <bryce> yeo
[22:16] <bryce> yep
[22:16] <jbarnes> gem got more memory
[22:17] <bryce> of course, virtual was 4x's the size, so stands to reason
[22:17] <bryce> I'm going to try 1281 1281 in case more memory simply means it takes longer to fill memory and thus longer to reproduce
[22:20] <bryce> froze
[22:21] <bryce> next I'll try 1400 1400.  If my guess is right, it'll still freeze but only after a longer period of time
[22:21] <bryce> dah, fsck kicking in.  
[22:22] <jbarnes> interesting that the back & front buffers have slightly different sizes in the large case
[22:41] <bryce> hrm, froze at 1400 virtual after not much longer...  1600 next
[23:12] <bryce> aha, 1600 froze after about 10 min
[23:35] <bryce> hmm, 1800 seems fine so far
[23:58] <bryce> 40 minutes at 1800 seems to be working ok
[23:59] <jbarnes> cool