Created attachment 320140 [details]
Screenshot of xchat showing the corrupted text
Description of problem:
When booting without nomodesetting things are starting to work pretty good with the latest rawhide, except that I suffer some text corruption (see the attached screenshot).
This is most easily triggered by rendering large amounts of text, for example switching between a fullscreen window, and a fullscreen xchat with a channel full of text.
Relevant lspci info:
03:00.0 VGA compatible controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (rev 9a)
03:00.1 Display controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) (rev 9a)
Created attachment 320141 [details]
xorg.log (with nomodeset present on the kernel cmdline)
My xorg.conf, contains the following, which might be highly relevant:
Option "AccelMethod" "EXA"
Last time I checked this is necessary to get Xv to work on r5xx cards.
*** This bug has been marked as a duplicate of bug 464896 ***
Could you please retest with xorg-x11-drv-ati-6.9.0-25.fc10.i386?
(In reply to comment #3)
> Could you please retest with xorg-x11-drv-ati-6.9.0-25.fc10.i386?
I already downloaded xorg-x11-drv-ati-6.9.0-25.fc10.x86_64 from koji and reproduced this bug with that version before opening this bug.
I can confirm the same bug on X1550 with xorg-x11-drv-ati-6.9.0-26.fc10.i386
*** Bug 466437 has been marked as a duplicate of this bug. ***
Coming from Bug 466437, with
01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro] (Secondary)
and xorg-x11-drv-ati-6.9.0-27.fc10.i386 and kernel-2.6.27-13.fc10.i686, I consistently see the problem when running without nomodeset. When running with nomodeset I see no problem. That is contrary to this bugs initial description.
I conclude that for me the kernels nomodeset doesn't play well together with the X driver.
Should I create another bug report, or is it really the same issue?
(In reply to comment #7)
> Coming from Bug 466437, with
> 01:00.1 Display controller: ATI Technologies Inc RV516 [Radeon X1300 Pro]
> and xorg-x11-drv-ati-6.9.0-27.fc10.i386 and kernel-2.6.27-13.fc10.i686, I
> consistently see the problem when running without nomodeset. When running with
> nomodeset I see no problem. That is contrary to this bugs initial description.
> I conclude that for me the kernels nomodeset doesn't play well together with
> the X driver.
> Should I create another bug report, or is it really the same issue?
Your seeing the same as the rest of us, so it is the same issue, but you seem to have trouble with double negations. You write: "I see the problem when running without nomodeset", so lets zoom in: "without nomodeset", now lets at spaces: "without no modeset" note that "without no" is the same as "with" so we get: "with modeset", so what you are saying is: "I see the problem when running with modeset", which is what this bug is about.
Hans, you are absolutely right. Obviously I didn't read the description well enough. I really don't know what I was thinking. Sorry for the confusion.
This should be fixed in xorg-x11-drv-ati-6.9.0-29.fc10
Please closed if it is.
I can confirm this is fixed now, closing.
(In reply to comment #11)
> I can confirm this is fixed now, closing.
Scrap that, I'm still seeing this although much less frequent now.
Also I'm not sure if this is related, but firefox and thunderbird drawing seems to be much slower now, very noticably slower. Also I think I'm only seeing this in firefox and thunderbird now.
I confirm that I see it occasionally (but probably more seldom) with
I did see corruption happen today. I got a block of speckled display after switching desktops. I haven't switched to the -47 kernel yet, but am otherwise up to date.
I saw a block around a line of text corrupted (all speckles) with the 18.104.22.168-52.fc10.x86_64 kernel. Mousing over the line got it to look normal again.
Problem remains with
*** Bug 469070 has been marked as a duplicate of this bug. ***
I saw another example today after firefox loaded a new page.
kernel-22.214.171.124-69.fc10 when it build should fix this please let me know.
It won't make it into rawhide just yet, so please pull from koji if you could.
I sync to dist-f10-updates-candiate regularly so I'll be testing this kernel in about 2 hours. The bigger problem is that I wasn't seeing the glitch very often and wasn't able to trigger it at will. I'll certainly report it if I see it, but won't be too confident about things if I don't.
I did notice something annoying with the tagging the xorg-x11-drv-ati-6.9.0-36.fc10 is tagged dist-f10-updates-candidate but xorg-x11-drv-ati-6.9.0-38.fc10 is tagged dist-f10 and f10-final and kernel-126.96.36.199-69.fc10 is tagged dist-f10-updates-candidate. So there ends up not being a single tag that will get both xorg-x11-drv-ati-6.9.0-38.fc10 and kernel-188.8.131.52-69.fc10.
I can do it manually, but its annoying.
I've been running the new kernel for some hours no and I no longer see the occasional text corruption I used to see, so this can be closed.
To compensate I've filed a new bug: bug 469378
This new one really is a show stopper (for me, with my work pattern) with regards to modesetting.
*** Bug 469576 has been marked as a duplicate of this bug. ***
I've upgraded to kernel-184.108.40.206-69.fc10.x86_64 and xorg-x11-drv-ati-220.127.116.11.fc10.x86_64, and while the "snow" is no longer there, instead now I get occasional blank spaces in my documents instead (that refreshing the window obviously fixes). Please reopen.
Maybe related to bug 459859, which involves text corruption reported on Intel chipsets.
Also you might want to try the -41 ati drv and the -73 kernel as there are graphics related fixes in both upgrades from what you are running.
I don't believe it relates to 459859 - the areas of the screen are very consistent with this bug and don't much resemble that one. I've upgraded, as per your advice, to -41 and will upgrade to -73, and will test the next time it's convenient to reboot.
I have seen some corruption in the outline of a button in firefox. Mousing over it didn't fix it but switching desktops back and forth did. Instead of the outline being a straight white line around a blackbox, it had short spikes more along the top than the bottom. It looked like maybe short horizontal sections of the border may have been turned vertically. The left side looked similar.
I am seeing gitches a lot more than last week, so I think something new got broken. Drop down boxes in firefox are especially affected. The glitches don't look the same as the previous ones. I am also seeing some drop down boxes now end up black instead of white with black text until I mouse over them. Most of my background is black, so maybe its now being redrawn when it should.
This is with the -73 kernel and -41 drv-ati on an r530 based card.
The -41/-73 combination is not usable - I get very reproducible X11 hangs with -41/-73 (the power button on my laptop still brings it down gracefully, but otherwise the system becomes unusable). I'm going back to
for now, but I'm willing to do more testing.
As far as the text corruption which is the subject of this bug, kernel -69 and later definitely fixed it for me. I've also seen the other symptoms, slowness, slight corruption in some gtk controls, incomplete redrawing, but these all seem like different issues.
Still fails (exactly same symptoms, very similarly looking corruction) with:
I take it, people got -69 kernel from Koji. It's not in Rawhide yet.
And yes, X is damn slow now. Unbearable.
I confirm #32: The text corruption this bug started out with has been coming and going and was pretty bad recently, but now it seems gone.
But I also confirm #29: Now I see firefox button corruption.
X has been slow "recently" but seems slightly faster now. But that's perhaps because I have rebooted...
So far none of the X hangs mentioned in #31.
xorg-x11-drv-ati-6.9.0-41.fc10.i386 no xorg.conf
Pete #33: yes, it's from koji - why don't you try it?
I am still seeing some corruption of buttons and what appears to be failures to redraw in Firefox.
This is with:
with an r530 based card.
This is not something we'd delay the release for, but we would happily take a fix for. Moving to F10 Target.
jkeating: Not delaying the release for this is OK. But then the Contingency Plan from https://fedoraproject.org/wiki/Features/KernelModesetting has to kick in and modeset be disabled! (Or at least be made opt-in)
As it is now users upgrading to f10 will get a very nice boot experience (except for 468526), but the system will be so annoying that it can't be used for serious use and they will have to add nomodeset manually. Overall that is a bad user experience.
airlied: still no ideas on what makes it happens, I've got a guess I made today to try and validate it.
airlied: wierd it doesn't happen that often to me that it annoys me.
airlied: its not a blocker and it won't trigger contingency.
airlied: as it doesn't stop an install from happening.
airlied: if we find the fix we can just push it out post GA.
Including a feature that has problems that produce a user experience markedly worse for some users seems like what the contingency idea is for - you can either set the quality bar very low and have people who had a working system suddenly have this sprung on them with the upgrade (all for sake of a feature that's nice but not actually very important), you can delay the release until it's fixed, or you can exercise the contingency. Do you really think the low quality bar is the best option? Is "it installs even if there are serious problems" really what was being aimed at when considering this feature for FC10?
I am still seeing an occasional corrupted button in Firefox with the -109 kernel and -46 ati driver.
can we try kernel -113 for the blank lines of text issue, which annoys more people I think.
the buttons is on my list still.
I am home sick today, so I didn't test the -113 kernel or -48 ati driver.
I'll try the latest stuff tomorrow morning.
The cases where I saw text missing was typically drop downs, not in paragraphs.
I don't know if that's the the same as what you are looking for above, but I'll specifically look for instances of that issue.
I haven't done a lot of testing, but I haven't seen any glitches using firefox in that short time.
I am using the -51 ati driver and the -116 kernel.
If I see some glitches later I'll make another comment.
Putting in a comment to clear the needinfo flag, mcepl I was not the person reporting the blank lines of text airlied asked info about. Please read the bug before putting in random flags.
I'm running kernel-18.104.22.168-116.fc10.x86_64 and xorg-x11-drv-ati-6.9.0-51.fc10.x86_64 on a X1950PRO. On boot, plymouth runs as usual but when fully booted, the gdm login box comes up while the background image is part plymouth, part corruption at the top. After 20-30 seconds, the regular login background appears. The only reason I mention this is because I only changed kernel and driver and this started happening. Once logged in though, things are normal. I get less corruption than in that last few driver/kernel combinations and I used to get missing lines of text in gnome-terminals which I can't seem to duplicate now. So for me, this seems to fix some problems. This is with compiz running too.
Here's some of the corruption I'm still seeing, mostly in evolution:
I did see some corruption of a drop down box. But things do seem to be happening less often than previously.
I just tried out the -117 kernel and the boot went OK up until X would normally start and it didn't. I couldn't get a vt either.
I didn't retest with -117, since by this morning I had already installed -120.
The problem at boot time didn't happen with -120. I also have the -54 ati driver.
While trying to see if I could get corruption to appear I did see a link with the text in the link corrupted using firefox.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
There have been bunch of bug fixes
Could you retest with the latest kernel
( -132 at the time of this writing )
You can get the latest kernel build here
And with the latest xorg-x11-drv-ati.
( -60 at the time of this writing )
You can get the latest xorg-x11-drv-ati build here
And report back if it either improves or fixes this issue..
Still happens with kernel -132 and xorg-x11-drv-ati -61
<sigh> I see no additional info request here so why has this been put in needinfo?
xorg-x11-drv-ati-6.9.0-62 may have a related fix, available there :
Could you test and report back ?
Thanks in advance
(In reply to comment #54)
> xorg-x11-drv-ati-6.9.0-62 may have a related fix, available there :
> Could you test and report back ?
> Thanks in advance
The text corruption problems are gone with -62 for me, I guess this bugno should be put for the bodhi update for -62 when it gets put in bodhi, so that bodhi will autoclose it when the update hits stable.
*** Bug 475555 has been marked as a duplicate of this bug. ***
xorg-x11-drv-ati-6.9.0-62 is on the mirrors, closing.
Thank you for the bug report. This particular bug was fixed and a update package
was published for download. Please feel free to report any further bugs you find.
You can obtain the updated package by typing 'yum update <package>' or using the