[kde-linux] Re: Panel widgets alwais to the left

[Duncan]

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 <alexdeucher at 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 <alexdeucher at gmail.com>
    Signed-off-by: Dave Airlie <airlied at redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh at suse.de>

The commit that fixed the problem for 2.6.37 was:

commit f3886f85cfde578f1d0ba6e40ac5f9d70043923b
Author: Alex Deucher <alexdeucher at 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 <alexdeucher at gmail.com>
    Reported-and-Tested-by: Duncan <1i5t5.duncan at cox.net>
    Cc: stable at kernel.org
    Signed-off-by: Dave Airlie <airlied at 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