[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] 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] or is it also enabled for pcie cards? [03:19] I assume the latter [03:19] I just started upgrading some machines with PCI 9250 (RV270) cards. [03:20] apparently, AGP is terrible [03:20] PCI is just as terrible :p [03:20] (not talking pcie) [03:20] I don't mean in the performance sense [03:20] even plain metacity without composite gets terrible corruption after an hours work or so [03:20] I don't mean it in that sense either [03:20] I mean in the number of gray hairs it causes [03:21] I mean in the amount that glyphs start looking like hieroglyphics rather than latin letters :p [03:21] gimp under metacity-with-compositing or compiz show immediate corruption when drawing [03:22] "AccelDFS false" fixes both the uncomposited-corruption-after-an-hour-or-so and the composited corruption in gimp [03:22] does it make sense that the old pci cards would have the same issue with that hook as an agp card would? [03:23] 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] 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] jbarnes: fresh lead on the X freeze issue [19:14] what news? [19:14] btw apw: ping [19:14] jbarnes: seems we have a patch in -intel from https://bugs.freedesktop.org/show_bug.cgi?id=19304#c13 [19:14] Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Major,Assigned] [19:14] bryce: removing it prevents the hangs? [19:14] 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] yes [19:15] ooh that's a good data point [19:15] I'm going to be doing more testing, but this is the first thing that's ever worked with compiz on [19:15] btw that particular patch was probably broken [19:16] 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] the most recent one is https://bugs.freedesktop.org/attachment.cgi?id=25116 [19:16] but it includes some pipestat writes that shouldn't exist in the 2d driver [19:16] bryce: yeah that was just a test hack [19:17] yeah the actual patch we have is one pitti made some mods to, but still based on that early version [19:17] https://bugs.freedesktop.org/show_bug.cgi?id=19304 has the latest on that [19:17] Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Major,Assigned] [19:17] short story is I still don't have a complete fix for pitti's bug [19:17] but I think we've narrowed it down [19:17] anyway if that really was the cause, then yay! [19:19] yeah... guess we need a cleaner procedure for handling test hacks vs. proven patches [19:19] http://launchpadlibrarian.net/26039104/109_i830-fifo-watermark-conservative.patch [19:19] that is the actual patch currently included in jaunty [19:22] well the most conservative stance would be not to apply anything that isn't already upstream (just like the linux stable rules) [19:22] that would have prevented this particular patch from getting applied [19:22] since I'm not happy enough to push it yet [19:24] * bryce nods [19:25] also, I think I may have reviewed this patch, but I did not upload it [19:27] (normally I'd not upload something I didn't get an ok on from you, that wasn't upstream) [19:29] yeah [19:31] 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] it could affect any configuration [19:31] since it it messes with the way the GPU fetches from RAM [19:33] hmm, two commenters on the bug report still seeing freezes [19:36] although, one reporter is a bit ambiguous, and the other I wonder might have a different freeze [19:37] 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] (fwiw, git bisecting mesa == pain) [19:41] cool thanks for the update [19:42] 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] (along with the pnp resource code he actually used; he fixed up one of the patches) [20:04] done [20:05] bryce, He [apw] might get back in later. He was somewhere travelling [20:06] jbarnes: ok, confirmed that the user I thought may see the problem with UXA does in fact have the problem with UXA [20:08] (with or without the patch 109 present) [20:08] sigh [20:08] but you thought that might be a separate bug? [20:40] jbarnes: yeah that's my gut feel [20:40] 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] jbarnes: I've gone back to stock mesa, and still after >20 min no freeze [20:41] also, fwiw performance seems to be better [20:42] bryce: im curious... how did you "go back to stock mesa"? what commands did you use? [20:43] just apt-get install mesa-common-dev et al [20:43] ok so when you bisected mesa you pulled bits into the debian git and installed an actual DEB each time? [20:43] yes [20:43] ah ok I see [20:44] well, a bit more complicated than that, but yeah I did the testing using debs [20:44] otherwise, I worried it'd make it difficult to get back to a stock config [20:44] yes I've tried "make install" with mesa and I had to re-roll the whole machine ;o [20:45] ouch [20:46] mnemo: yeah I can imagine [20:46] 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] oh, that's smart [20:46] yeah I had something like that on one of my psb test boxes that I used to have to reimage regularly [20:47] 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] jbarnes: oh crap [20:47] jbarnes: I just noticed I had UXA turned on. No wonder it was faster :-P [20:48] 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] heh [20:49] mnemo: correct [20:54] jbarnes: rats, still freezes [20:54] arg [20:55] maybe you should just give up and move to uxa/dri2 :) [20:55] 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] I guess its mid 2011 for dapper and early 2011 for jaunty [21:01] :- [21:01] +/ [21:02] * bryce returns to being out of ideas [21:02] bryce: which bug are you trying to figure out? and what hardware does it repro on? [21:03] bug 359392 on i965 [21:03] Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Unknown,Confirmed] https://launchpad.net/bugs/359392 [21:03] https://wiki.ubuntu.com/DesktopTeam/i965Users [21:05] ah right the blacklist bug [21:06] gods I'm sick of this bug [21:24] bryce: btw we've been talking about providing a multi-drm master patch for 2.6.28 kernels [21:24] bryce: it would allow for acceleration even on secondary servers (e.g. for fast user switching) [21:26] interesting, tell me more? [21:31] it's a fairly small kernel patch that allows the 2d drivers to drop their drm master status [21:31] which allows a subsequent server start to be a drm master, which means it can initialize all the stuff required for 3d [21:31] so no more second class status for secondary servers [21:31] they'd all be equal [21:32] ok, so on FUSA, server #1 could drop drm master status, and server #2 could pick it up during the switch? [21:32] right [21:32] or at startup [21:32] is this unnecessary for 2.6.30, or already present there? [21:32] yeah 2.6.29 and 2.6.30 already have support for it [21:33] ok [21:33] you'll see messages in the log about setting and dropping master [21:39] jbarnes: https://wiki.ubuntu.com/DesktopTeam/i965Users [21:39] jbarnes: interesting that there seems to be a strong correlation between amd64 use and seeing the freeze [21:40] jbarnes: oddly, I seem to be one of the contrary points [21:42] yeah I was curious about that... seems only one other i386 user can reproduce the problem with the script [21:43] jbarnes: are you 64-bit or 32-bit? [21:44] 64 bit [21:47] 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] 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] did anybody had the issue using a virtual setting? [21:49] I just noticed that several users said not getting the freeze and having virtual set [21:49] I'm in this case === kees___ is now known as keescook === keescook is now known as kees [21:59] I'm testing that theory now; seems to be working [21:59] jbarnes: I don't generally have trouble reproducing it now, using the repro.sh script so haven't tried that. [22:00] Typically I get the freeze in under 10 min of starting the repro.sh script [22:00] oh then instead you could unmounting your swap partition [22:00] w/swapoff [22:00] and make sure you don't have a swap file [22:00] ok [22:00] just in case it's the swapping code that's causing the failure [22:00] jbarnes: "that theory" is the virtual setting one I think, not the swap use one [22:01] ah [22:02] ok, hmm seems seb128's theory works on my hw [22:02] jbarnes: any idea why it would work with Virtual 2048 2048 but freeze when setting automatically (to 1280 1280) [22:02] I'm one of those who never had the freeze but I've a virtual setting since jaunty start I think [22:02] seb128: if you remove that, then do you get freezes? [22:02] I tried once to set 2 screens using the xrandr capplet and it did that for me [22:03] we might have a bogus check in there that disables certain features with a 2k width on 965 [22:03] (945 has that limit but 965 is bigger) [22:03] 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] seb128: yeah I notice a performance difference as well [22:04] I'm also one of those guys who never had performances issues in jaunty ;-) [22:04] fwiw, mdz's repro.sh script always triggers the freeze for me within about 15min [22:04] I'm wondering if all that is thanks to the virtual setting ;-) [22:06] 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] that's still a workaround though [22:06] but maybe it could give some clue on the issue [22:07] at least, it's a better workaround than our current workaround of shutting off compiz entirely [22:07] assuming it works for everyone and doesn't cause some other regression [22:07] ok looks like even 2047 2047 works without freezing [22:07] right [22:08] * bryce tries 1280 1280 [22:14] yep, froze [22:14] mmm [22:14] * bryce tries 1281 1281 [22:14] what's the diff in your X logs between those two cases? [22:14] * bryce looks [22:15] http://pastebin.ubuntu.com/159638/ [22:16] ok so exa offscreen size changed significantly [22:16] yeo [22:16] yep [22:16] gem got more memory [22:17] of course, virtual was 4x's the size, so stands to reason [22:17] 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] froze [22:21] 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] dah, fsck kicking in. [22:22] interesting that the back & front buffers have slightly different sizes in the large case [22:41] hrm, froze at 1400 virtual after not much longer... 1600 next === CShadowRun is now known as cshadowrun [23:12] aha, 1600 froze after about 10 min [23:35] hmm, 1800 seems fine so far [23:58] 40 minutes at 1800 seems to be working ok [23:59] cool