Bug 847818

Created attachment 604074 [details]
Screen corruption

I'm also getting graphical corruption on 3.5.x. I've attached a snapshot showing some of the issues. Images in Firefox after a few minutes are likely to get pretty bad, especially with scrolling. Running Google Earth is likely to bring a rapid halt to proceedings.

I, however, have an nVidia GeForce 8300GS. I tried the nVidia proprietary drivers to see if the problem was confined to nouveau but they were even worse.

3.4.6 also works flawlessly for me too.

I tried booting with nomodeset but I get stuck with vesa resolution, maybe vesa driver too, no time to check more for now.

From lspci -vvv, this is my RS90/X1200 where I feel the same issue:

01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] (prog-if 00 [VGA controller])
        Subsystem: Dell Device 0206
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 19
        Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at fe9f0000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at ee00 [size=256]
        Region 5: Memory at fea00000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: <access denied>
        Kernel driver in use: radeon

Just pinging this problem: current kernel 3.5.3-1.fc17 *still* doesn't fix it.

IMHO this may be a kernel driver problem and not an X driver problem.

I just install kernel 3.5.3-1.fc17.x86_64 on my Dell inspiron 1521 with a Radeon RS690M video card and I have the same issue of  Desktop fonts get distorted and black areas appear on the screen. 

Is anyone working on a fix or do I keep using FC16?

You can use Fedora 17, but you must install the latest 3.4.6 Linux and don't boot with more recent Linux versions.

Yeah, sucks as you miss out on bug fixes, specially security fixes... brrr...

This problem persists on Fedora 18 Alpha! I'm uploading a video on http://youtu.be/ns-YlQVJ7h0 (should be there in half an hour or so).

Can someone please add this bug to the Fedora 18 Radeon tests?

Ok, I was able to add it. https://fedoraproject.org/wiki/Test_Day:2012-09-26_Radeon#cite_note-bz847818-40

But this bug should be marked on Fedora 18's bug list. This bug makes the system unusable with X.

Meanwhile, the video has been completely uploaded.

Discussed at 2012-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-03/f18-beta-blocker-review-2.2012-10-03-16.00.log.txt . We agreed that this is rejected as a blocker, on the long held precedent that we usually don't take graphics bugs that only affect single adapters or small families of adapters as blockers, especially not for Beta; usually graphics bugs have to affect a wider range of adapters to be taken as blocker issues.

Accepted as NTH, there's a similar precedent that we take fixes for showstopper graphics issues like this through the freeze as long as they're tested.

Well, it's certainly a show stopper for me and the machine I work with 90% of my work days. :)

I agree it's not a show stopper for a beta release, though that means there's very little I'll be able to help other than ping when it comes out whether it has improved or not.

Anyway, the conversation shows it was a very light headed decision... "I don't think it's all that common" is not a very good argument.

Perhaps better would be a percentage of RS690 cards among radeon usage on smolt profiles... I'm willing to bet it's more common that not, specially on laptops but I'll cave for good numbers (and an analysis of smolt profiles is a much better number than I could gather).

All in all, it's better "a scarcely tested but specific to this card" test that makes it at least work than a "well tested that is not specific to this card" (although the earlier should be, in time, replaced by the later).

rui: there is a sufficiently wide range of graphics hardware in use that *any* single adapter falls well below 5% of all extant systems, in the stats. Probably lower than 3%, honestly, and I don't think any single Radeon adapter would be close to that.

We go to smolt when we have to, but it's very tricky to use that data in all honesty, because it's not very well formatted or curated. smolt gives PCI IDs in base 10, for only the most egregiously dumb example. So we only go to the trouble when we know that at least a few different cards are affected by a bug. smolt is actually being retired at present; in the long run it'll be replaced by a new system which I'm hoping will be easier to use for these purposes.

Blocker bug meetings can get a bit kooky sometimes just because they go on so damn long and they get tedious and repetitive, but our hearts are in the right place, believe me. =) The principle that we can't block on single-adapter bugs is a solid one and established for a very good reason: it's just not a realistic standard to set. There is a vast range of graphics hardware out there, and comparatively few developers working on the free graphics drivers, even fewer of whom Fedora is in a position to exert any particular influence (of the form 'fix this bug by next week or else') over. We just don't have the development resources to be able to convincingly commit to fixing all showstopper graphics bugs, though I would love to if we could. If you go look through Bugzilla for nouveau, radeon and intel right now you'll likely find, oh, I'd say at least two or three dozen single-system showstoppers like yours, and those are just the ones that have been caught and reported. We just do not have the developer time to fix them all.

I usually say, with a reasonable degree of confidence, that no distributor has ever shipped a release of any Linux distribution which worked out of the box on every graphics card around, even if you limit it to just Intel, NVIDIA and AMD. Not Fedora, not Red Hat, not Ubuntu, not Debian, not SUSE, nobody. It is close to being a practical impossibility. A hacky way to get closer is to start implementing blacklists of known broken cards and forcing them to 'vesa', and for a more consumer-facing project like Mandriva or Ubuntu this can make sense, but given the goals of Fedora, we consider maintaining such a blacklist to be ultimately a waste of development resources. So we set a high bar for graphics blockers, on practical grounds. If someone hired us a dozen X developers we could re-consider.

Hope that clarifies the ground somewhat. I know it's not the best thing to hear, but it's what we have to work with.

You look like you've been around a while so you likely know all this, but there are of course things you can do to try and get up and running with F18. Install with the vesa driver and then use the proprietary driver; this is not official advice as we do not advise the use of closed source software, but as a practical matter, a closed source driver that works is probably more use than an open one that doesn't. =) 'Just grit your teeth and bear using vesa permanently' is an option, of course. Try using a non-GL desktop like Xfce or MATE rather than GNOME; it may be the bug affects only the GL-rendered GNOME (yes, even the login screen is GL-rendered these days, 'gdm' since F17 is in fact a special instance of gnome-shell). One of those might get you up and running.

FWIW, I did take a quick look at the smolts data, and you're right that this is a very popular adapter. It has two entries in the smolts device table ultimately - http://www.smolts.org/reports/view_device/RS690M%20%5BRadeon%20X1200%20Series%5D and http://www.smolts.org/reports/view_device/RS690%20%5BRadeon%20X1200%20Series%5D . Each page appears to list 1000 devices, which rather looks like a cut-off. There are 3,095,805 systems registered in Smolt; 1% of registered systems would be 30,000, more or less. So if we set our cut-off at 3% of all systems in Smolt, that'd be 100,000. I'll have to ask around if it's possible to get a non-cut-off listing for the RS690 adapters.

Assuming that all rs690 GPU are affected is wrong. Same GPU different motherboard and you get different result. For instance :

So tested with http://kojipkgs.fedoraproject.org//work/tasks/5340/4555340/Fedora-18-Nightly-20121003.08-x86_64-Live-desktop.iso

on rs690 desktop (ASUS MOTHERBOARD M2A-VM HDMI) and f18 works without issue or corruption.

Do you know if your GPU as a sideport memory ?

rui: on the 'blocker status' question, I remembered we have a blocker bug FAQ page and put up a detailed description of the graphics blocker precedent there - https://fedoraproject.org/wiki/Blocker_Bug_FAQ#Graphics_card_failures . hope that at least makes our reasoning clear, and we can refer to it in future, so thanks for the prompting. :)

@Adam: Oh, I think the reasoning is quite clear, just that I had an idea that this kind of card was a bit more common that believed by the interlocutor, and I'm terribly afraid for Linux security bugs on my laptop and if it isn't fixed by the time Fedora 18 comes out I'll be in a bit of trouble.

@Jerome: thanks for also taking a look into this issue, you're one of the people I most have to thank for having support for my laptop's graphics card... I still remember the days when I was swapping radeon-hd and radeon almost weekly in order to improve support (better non accelerated 1280x800 than the first 4 months with 1024x768 VESA...)

I'll only be able to check tomorrow or the following day as I'm on an extended weekend, but how can I check whether that RS690 included in my job's laptop has or not sideport memory?

I tried  Jerome Glisse suggestion and booted to Fedora-18-Nightly-20121003.08-x86_64-Live-desktop.iso on my Dell inspiron 1521 that has the Radeon RS690M video card.  I can't stand GNOME 3 desktop, but the GUI works fine. The VGA compatible controller: Advnced Micro Devices [AMD] nee ATI RS690M [Radeon X1200 Series] seems to be working.

So it might be a bug only affecting kde ... I will try some live image of kde latter.

Definitely not related to KDE unless... suddenly... GDM, GNOME 3 and Enlightenment suddenly became KDE :)

I'll try a more recent nightly and report.

Screenshot attached to this bug shows kde so i was assuming everyone affected had kde

hehe, no problem. My linked video didn't show KDE, though.

Trying out the above mentioned nightly, http://kojipkgs.fedoraproject.org//work/tasks/5340/4555340/Fedora-18-Nightly-20121003.08-x86_64-Live-desktop.iso I don't get any of the corruptions with current Linux versions for Fedora 17 or the Fedora 18 Alpha

So I'm hopeful I'll get a working Fedora 18.

GNOME 3 is still terribly slow in this card, that hasn't improved, and I guess it can't be helped :)

can you try the Beta TC3 live build? https://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC3/Live/ , and let us know how that goes. thanks!

I just tried Fedora-18-Beta-TC3-x86_64-Live-XFCE.iso and it works fine. Fonts all lookgood and GUI is clean. So it works on a Dell inspiron 1521 that has the Radeon RS690M video card. Do you need other versions tested (i.e. GNOME, KDE. etc)? I only tested the Xfce version.

@Adam: with that Beta TC3 live build it still works, and it's actually a teeny bit faster.

Glad to see the fix hasn't been a one shot fluke :)

Great. The latest kernel build, https://admin.fedoraproject.org/updates/FEDORA-2012-15669/kernel-3.6.1-1.fc18 , has now gone stable, so we can drop this as an F18 release blocker - it's clearly fixed in latest F18. Leaving the bug open, though, as it's filed against F17.

You might be able to help Jerome fix it for F17 by grabbing the last few kernels and booting them one by one to try and isolate exactly when the bug was fixed, that should help Jerome figure out what the fix for this was and backport it to F17.

How do I get all the Linux packages from F18 before http://kojipkgs.fedoraproject.org//work/tasks/5340/4555340/Fedora-18-Nightly-20121003.08-x86_64-Live-desktop.iso ?

Do they work on F17?

If so, I'd gladly help...

You can download older builds (going back a few weeks, they get garbage-collected after a while) at http://koji.fedoraproject.org/koji/ . Type 'kernel' in the search box at top-right and hit enter, look for the fc18 builds.

F18 kernels should probably install and boot okay on F17, yeah.

Haven't had time to test those Linux versions but meanwhile the Linux in kernel-3.5.5-2.fc17.x86_64 apparently fixed it, that or any other suspect in the list below (though I'm pretty convinced it was a kernel thing):

[rms@roque ~]$ sudo grep "Oct 09" /var/log/yum.log 
Oct 09 10:27:48 Updated: 1:libreoffice-ure-3.5.6.2-5.fc17.x86_64
Oct 09 10:28:06 Updated: nspr-4.9.2-1.fc17.x86_64
Oct 09 10:28:08 Updated: 1:autocorr-en-3.5.6.2-5.fc17.noarch
Oct 09 10:28:10 Updated: 1:autocorr-pt-3.5.6.2-5.fc17.noarch
Oct 09 10:28:31 Updated: 1:libreoffice-opensymbol-fonts-3.5.6.2-5.fc17.noarch
Oct 09 10:28:40 Updated: 1:libreoffice-writer-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:18 Updated: 1:libreoffice-core-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:19 Updated: 1:libreoffice-graphicfilter-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:20 Updated: 1:libreoffice-draw-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:22 Updated: 1:libreoffice-pdfimport-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:24 Updated: 1:libreoffice-impress-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:29 Updated: 1:libreoffice-presenter-screen-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:34 Updated: 1:libreoffice-langpack-pt-PT-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:37 Updated: 1:libreoffice-calc-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:38 Updated: 1:libreoffice-langpack-en-3.5.6.2-5.fc17.x86_64
Oct 09 10:29:45 Updated: gnome-shell-3.4.1-6.fc17.x86_64
Oct 09 10:29:48 Updated: openldap-2.4.32-3.fc17.x86_64
Oct 09 10:29:52 Updated: poppler-data-0.4.5-6.fc17.noarch
Oct 09 10:29:54 Updated: mysql-libs-5.5.28-1.fc17.x86_64
Oct 09 10:29:56 Updated: automake17-1.7.9-16.fc17.noarch
Oct 09 10:29:57 Updated: usbredir-0.4.4-1.fc17.x86_64
Oct 09 10:29:58 Updated: libmtp-1.1.5-1.fc17.x86_64
Oct 09 10:29:59 Updated: taglib-1.8-2.fc17.x86_64
Oct 09 10:32:41 Installed: kernel-devel-3.5.5-2.fc17.x86_64
Oct 09 10:32:43 Updated: python-lxml-2.3.5-1.fc17.x86_64
Oct 09 10:32:47 Updated: kernel-headers-3.5.5-2.fc17.x86_64
Oct 09 10:32:50 Updated: directfb-1.5.3-9.fc17.x86_64
Oct 09 10:33:02 Installed: kernel-3.5.5-2.fc17.x86_64
Oct 09 10:33:03 Updated: nspr-4.9.2-1.fc17.i686
Oct 09 10:33:06 Updated: openldap-2.4.32-3.fc17.i686

Didn't say it explicitly, but since it #worksforme now, as far as I'm concerned this bug is now fixed and can be closed for Fedora 17.

It's most likely fix by fence fix serie in the kernel.