| * 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:18 |
| crdlb | I assume the latter | 03:19 |
| cwillu | I just started upgrading some machines with PCI 9250 (RV270) cards. | 03:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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) | 03:23 |
| 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 | 13:21 |
| bryce | jbarnes: fresh lead on the X freeze issue | 19:13 |
| 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 |
| ubottu | Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Major,Assigned] | 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:14 |
| 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:15 |
| 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:16 |
| 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 |
| ubottu | Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Major,Assigned] | 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:17 |
| 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:19 |
| 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:22 |
| * bryce nods | 19:24 | |
| bryce | also, I think I may have reviewed this patch, but I did not upload it | 19:25 |
| bryce | (normally I'd not upload something I didn't get an ok on from you, that wasn't upstream) | 19:27 |
| jbarnes | yeah | 19:29 |
| 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:31 |
| bryce | hmm, two commenters on the bug report still seeing freezes | 19:33 |
| bryce | although, one reporter is a bit ambiguous, and the other I wonder might have a different freeze | 19:36 |
| 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:37 |
| bryce | (fwiw, git bisecting mesa == pain) | 19:38 |
| jbarnes | cool thanks for the update | 19:41 |
| 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) | 19:42 |
| bryce | done | 20:04 |
| bryce | <smb_> bryce, He [apw] might get back in later. He was somewhere travelling | 20:05 |
| bryce | jbarnes: ok, confirmed that the user I thought may see the problem with UXA does in fact have the problem with UXA | 20:06 |
| 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:08 |
| bryce | jbarnes: yeah that's my gut feel | 20:40 |
| bryce | <apw> 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:40 |
| 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:41 |
| mnemo | bryce: im curious... how did you "go back to stock mesa"? what commands did you use? | 20:42 |
| 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:43 |
| 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:44 |
| bryce | ouch | 20:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| bryce | mnemo: correct | 20:49 |
| bryce | jbarnes: rats, still freezes | 20:54 |
| jbarnes | arg | 20:54 |
| jbarnes | maybe you should just give up and move to uxa/dri2 :) | 20:55 |
| bryce | in fact, that was eric's only advice :-( | 20:55 |
| * 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 | 20:57 |
| bryce | :- | 21:01 |
| bryce | +/ | 21:01 |
| * 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:02 |
| bryce | bug 359392 on i965 | 21:03 |
| ubottu | Launchpad bug 359392 in xserver-xorg-video-intel "[i965] X freezes starting on April 3rd" [Unknown,Confirmed] https://launchpad.net/bugs/359392 | 21:03 |
| bryce | https://wiki.ubuntu.com/DesktopTeam/i965Users | 21:03 |
| mnemo | ah right the blacklist bug | 21:05 |
| bryce | gods I'm sick of this bug | 21:06 |
| 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:24 |
| bryce | interesting, tell me more? | 21:26 |
| 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:31 |
| 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:32 |
| bryce | ok | 21:33 |
| jbarnes | you'll see messages in the log about setting and dropping master | 21:33 |
| 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:39 |
| bryce | jbarnes: oddly, I seem to be one of the contrary points | 21:40 |
| jbarnes | yeah I was curious about that... seems only one other i386 user can reproduce the problem with the script | 21:42 |
| bryce | jbarnes: are you 64-bit or 32-bit? | 21:43 |
| jbarnes | 64 bit | 21:44 |
| 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:47 |
| 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:49 |
| === kees___ is now known as keescook | ||
| === keescook is now known as kees | ||
| 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. | 21:59 |
| 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:00 |
| jbarnes | ah | 22:01 |
| 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:02 |
| 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:03 | |
| 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:04 |
| 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:06 |
| 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:07 |
| * bryce tries 1280 1280 | 22:08 | |
| 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:14 | |
| bryce | http://pastebin.ubuntu.com/159638/ | 22:15 |
| jbarnes | ok so exa offscreen size changed significantly | 22:16 |
| bryce | yeo | 22:16 |
| bryce | yep | 22:16 |
| jbarnes | gem got more memory | 22:16 |
| 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:17 |
| bryce | froze | 22:20 |
| 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:21 |
| jbarnes | interesting that the back & front buffers have slightly different sizes in the large case | 22:22 |
| bryce | hrm, froze at 1400 virtual after not much longer... 1600 next | 22:41 |
| === CShadowRun is now known as cshadowrun | ||
| bryce | aha, 1600 froze after about 10 min | 23:12 |
| bryce | hmm, 1800 seems fine so far | 23:35 |
| bryce | 40 minutes at 1800 seems to be working ok | 23:58 |
| jbarnes | cool | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!