Alex Schuster posted on Thu, 14 Apr 2011 00:03:04 +0200 as excerpted: > I updated my kernel (2.6.38-ck) and installed xorg-1.10.0.902. First, I > rebooted with gallium enabled (without nomodeset kernel parameter). In > the early boot phase, right when the font changes, I got a distorted > image of my grub splash screen, in wrong colors. System hangs, I can > reboot with Alt- SysRq-B. > With nomodeset kernel parameter, all looks fine. at first. But still, > there are little distortions sometimes when scrolling. I could live with > that, but after a few minutes, X crashes. Without Compositing (toggled > by Alt-Shift- F12), everything is okay. > Then I tried Xort 1.9.5. Without Compositing, all is fine. I think I saw > a little distortion inthe TV-Browser application, but could not > reproduce this. I see a little more graphic problems with compositing > enabled, but it would be tolerable. Again, X crashes after some minutes. > So I switched to ati-drivers-11.3. This works, no graphic problems at > all. > Let's see if the memory leak problem still happens.
FWIW, as I said, solid graphics here, with the free/native radeon driver, kms, radeon rv730 chip, model hd4650. But I don't use gallium, I use the classic DRM2 driver. I did try gallium at one point but had serious issues (IDR what, now, but it was bad enough I reverted pretty quickly!) and reverted to the classic DRM2 driver. But definitely KMS. I enabled that while the choice was still in the kernel staging area, and never looked back. OH!! One other **MAJOR** thing to add. If per chance you still have legacy AGP connected graphics instead of the newer PCI-E, there was an entire kernel series or two that was bad, at least here, without reverting a particular commit, for anything in the r7xx series chips (your hd3200 is an rs780, according to the table in the radeon manpage, so would likely be affected). Let me lookup the kernel bug and get the exact kernel versions... OK, 2.6.35 itself was fine but the stable series added the bad commit after it was applied to the 2.6.36 development kernel, so 2.6.35.x is bad. The bad commit went in early in the 2.6.36 cycle and the bug wasn't fixed the whole cycle (unless it made it into stable after I was already on 2.6.37-pre-releases), so 2.6.36 is definitely bad and to my knowledge so is that whole stable series, tho they might have fixed it at some point. (I run a direct git kernel here, and after bisecting the problem in early 2.6.36, I created a commit reverting the problem commit that I continued to apply locally, thru the whole 2.6.36 cycle and into 2.6.37.) The fix commit went in between 2.6.37-rc5 and 2.6.37-rc6, so thru rc5 is bad, rc6+ and 2.6.37 release is good. If you're interested in the kernel bug filing itself, here it is: https://bugzilla.kernel.org/show_bug.cgi?id=19002 The bad commit (2.6.36 tree, the 2.6.35 stable tree had a different ID of course) was: commit 44437579efca258e3c4a09f59838c8f933611990 Author: Alex Deucher <alexdeuc...@gmail.com> Date: Mon Jul 26 18:51:53 2010 -0400 drm/radeon/kms/r7xx: add workaround for hw issue with HDP flush commit 812d046915f48236657f02c06d7dc47140e9ceda upstream. Use of HDP_*_COHERENCY_FLUSH_CNTL can cause a hang in certain situations. Add workaround. Signed-off-by: Alex Deucher <alexdeuc...@gmail.com> Signed-off-by: Dave Airlie <airl...@redhat.com> Signed-off-by: Greg Kroah-Hartman <gre...@suse.de> The commit that fixed the problem for 2.6.37 was: commit f3886f85cfde578f1d0ba6e40ac5f9d70043923b Author: Alex Deucher <alexdeuc...@gmail.com> Date: Wed Dec 8 10:05:34 2010 -0500 drm/radeon/kms: don't apply 7xx HDP flush workaround on AGP It should be required for all 7xx asics, but seems to cause problems on some AGP 7xx chips. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=19002 Signed-off-by: Alex Deucher <alexdeuc...@gmail.com> Reported-and-Tested-by: Duncan <1i5t5.dun...@cox.net> Cc: sta...@kernel.org Signed-off-by: Dave Airlie <airl...@redhat.com> But since that commit that was in by 2.6.37-rc6, it has been smooth sailing, graphics-wise. Note that I tend to stay as leading edge as possible both X/mesa/ddx and kernel-wise, sometimes running live git versions of various bits of X and drivers, and /normally/ running live-git kernel, tho I tend to skip the merge phase and first rc, and don't start testing until after rc2 (with 2.6.39, I happened to git-pull on 2.6.39-rc3 exactly, so that was my first test, but I'm not on it as there's some sort of login bug affecting it, here, that I'll research and file one of these days if it's not fixed first and not already filed that I can find). The point is, unless there's something wrong, I normally run latest release version at least, and often testing or live-git, of the whole graphics stack, kernel, xorg/ mesa/ddx, kde. Thus, bugs that tend to hit people when they update one component of that stack but are dragging on others don't tend to hit me, because I'm never that far behind on any bit of the stack. Of course, being that leading edge, I sometimes see bugs due to that... and fall back a version or so to something stable on whatever's involved, if I find the bleeding edge bugs bad enough. But even then, I still tend to be quite out in front of the 6-month-cycle binary-release distro folks, who are often 9 months behind (the six months of the release, plus three months of stabilizing and testing before the release), by the time their next release comes out, and already three months behind the day a release hits the net! No /wonder/ they have problems with the latest kde, as the rest of the system they're running is an average of six months old, sometimes older! Of course at least in theory, the kde release that comes with the distro release has been tested and should work with the whole set of software on that release, but as we all know, theory doesn't always match reality. Sometimes it works as it's supposed to, sometimes not. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
