Description of problem: Testing all my radeon cards, I installed fedora 13 beta (plus updates) on a system with this card: 01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200] (rev 01) 01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01) (not using the secondary TV output). At first glance, everything seems to work well, I can even turn on compiz and wiggly windows and cube desktop, but the cube desktop is really really dark when it is rotating the cube. I try installing an running the neverputt game (part of the neverball package). It is also exceedingly dark. It is like trying to play golf by moonlight. I try running the gltestperf program from mesa-demos, and it actually does run to completion, but about 1/2 way through one of the benchmarks the window decorations and menus all suddenly disappear like metacity and some othe bit of gnome crashed. Examining /var/log/messages I find scads of stuff like [drm:radeon_fence_wait] *ERROR* fence(de2265f0:0x0000AD76) 510ms timeout going to reset GPU. I'll attach all the various logs and wot-not to this bug. Version-Release number of selected component (if applicable): mesa-libGL-7.8-0.18.fc13.i686 mesa-libGL-devel-7.8-0.18.fc13.i686 mesa-demos-7.8-0.18.fc13.i686 mesa-libGLU-7.8-0.18.fc13.i686 mesa-dri-drivers-7.8-0.18.fc13.i686 mesa-libGLU-devel-7.8-0.18.fc13.i686 xorg-x11-drv-ati-6.13.0-1.fc13.i686 kernel-PAE-2.6.33.2-41.fc13.i686 How reproducible: The darkness of neverputt and desktop on cube are 100%. I only ran the gltestperf program once. Steps to Reproduce: 1.see above 2. 3. Actual results: various strange results Expected results: actually that was kinda what I expected, but it would sure be nice for an ATI card to actually work flawlessly for once :-). Additional info:
Created attachment 407311 [details] Xorg.0.log
Created attachment 407312 [details] /var/log/dmesg
Created attachment 407313 [details] /var/log/messages I took the liberty of filtering out the vast spew of gdm-* DEBUG messages to cut the size of this file in half and make it easier to see things :-).
Created attachment 412691 [details] screenshot from bad display I was able to take a screenshot of the neverputt screen showing the extreme dark background (compared to the normal sample course thumbnails shown in the foreground). This also shows a new feature I didn't notice before, some red lines that flicker on and off at the top of the window. The hardware on this system is the same, but I recently re-installed from the RC2 livecd (32 bit) so the versions of all the drivers match whatever shipped with RC2 Fedora 13.
Created attachment 412692 [details] screenshot from working fedora 13 system Just for comparison, here's a screenshot of neverputt running on my 64 bit fedora 13 system which seems to have the most functional video card.
My screen suddenly went blank on saturn. I could ssh from jupiter, but shortly after the connection died and saturn had shut itself down - found it had switched off. Went through /var/log/messages, and captured every line with 'radeon' since the previous boot. Will attach file. A lot of entries like: Jun 4 10:18:55 saturn kernel: [drm:radeon_fence_wait] *ERROR* fence(ffff8802118c6440:0x003AD3A8) 816ms timeout Jun 4 10:18:55 saturn kernel: [drm:radeon_fence_wait] *ERROR* last signaled fence(0x003AD3A8) Jun 4 10:18:58 saturn kernel: [drm:radeon_fence_wait] *ERROR* fence(ffff8800cf6f2780:0x003AD3B8) 505ms timeout going to reset GPU Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: GPU softreset Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xA0003030 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20001040 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00007FEE Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00000001 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_000E60_SRBM_SOFT_RESET=0x00000402 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_008010_GRBM_STATUS=0x00003030 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003 Jun 4 10:18:58 saturn kernel: radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20000040
Created attachment 421084 [details] selected radeon entries from /var/log/messages
# uname -a Linux saturn 2.6.32.12-115.fc12.x86_64 #1 SMP Fri Apr 30 19:46:25 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux up to date Fedora 12 install AMD 810 quad core 64 bit 8 GB DDR3 RAM 5 * 500GB in software RAID-6 configuration ASUS M4A78T-E motherboard Bus 001 Device 004: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000
(In reply to comment #3) > Created an attachment (id=407313) [details] > /var/log/messages > > I took the liberty of filtering out the vast spew of gdm-* DEBUG messages to > cut the size of this file in half and make it easier to see things :-). In the end of really awfully long file there are lot of errors in relation to DRM radeon module.
I tried the same 9200 card after installing f13 final from DVD image then getting all updates. The extreme darkness still happens when doing things like rotating the desktop with desktop effects turned on, so it doesn't look like anything improved since the beta.
Ive seen the same on my system, just much worse. First time I saw it I guess was during the upgade from FC10 to FC13, where the upgrade stopped in one of the last steps. Installing from scratch with FC13 also was hanging in one of the last steps. But by turning the screen on the laptop I could see the shades of a message box. Trying to click wildy on that area made the install finish. But the installed system only runs shortly. When starting to use graphics the error comes up again. Some times the screen goes compeletely black, other times it just hangs. And often the network to the computer is lost too. I once managed to log in with ssh. I would say that this bug is a show stopper for FC13. I will try to go back to an earlier release. 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200 M] (prog-if 00 [VGA controller]) Subsystem: Uniwill Computer Corp Device 2a05 Flags: bus master, 66MHz, medium devsel, latency 66, IRQ 26 Memory at d0000000 (32-bit, prefetchable) [size=256M] I/O ports at 9000 [size=256] Memory at c0000000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at c0020000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit- Kernel driver in use: radeon Kernel modules: radeon, radeonfb
If it is of any help tracking down the problem... Even with the latest Fedora updates, I still get this problem with Fedora 12. Linux saturn 2.6.32.14-127.fc12.x86_64 #1 SMP Fri May 28 04:30:39 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux (I would like to upgrade to Fedora 13, but it appears from the above comments, that the problem persists there as well.)
I tried Fedora 14 Beta + updates on the same system with the 9200 card, and the extreme darkness with any 3D operations like the rotating desktop effect still shows up: xorg-x11-drv-ati-6.13.1-0.3.20100705git37b348059.fc14.i686 mesa-dri-drivers-7.9-0.8.fc14.i686 xorg-x11-server-Xorg-1.9.0-13.fc14.i686
any chance you could give a final F14 + kernel from koji a go? http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.9/64.fc14/
OK, same hardware, updated to f14 final and with updates applied, I have these versions of possibly relevant packages (including the kernel from koji above): kernel-2.6.35.9-64.fc14.i686 xorg-x11-drv-ati-6.13.1-0.3.20100705git37b348059.fc14.i686 mesa-libGLU-devel-7.9-2.fc14.i686 mesa-libGLU-7.9-2.fc14.i686 mesa-libGL-devel-7.9-2.fc14.i686 mesa-demos-7.9-2.fc14.i686 mesa-libGL-7.9-2.fc14.i686 mesa-dri-drivers-7.9-2.fc14.i686 The results are: GL stuff still turns very dark (rotating desktop on a cube as an example) The mesa-demos gltestperf no longer crashes metacity, but it still generates a gazillion errors in the /var/log/messages file and the screen keeps flickering on and off in each benchmark till the size of items gets to around 50 or below near the end of each benchmark. The only benchmark with no screen flickering is the last one (#5). I'll attach the /var/log/messages with all the radeon errors at the end.
Created attachment 464777 [details] /var/log/message to go with comment 15 Gazillions of radeon related kernel walkbacks at the end of this file.
does booting with radeon.agpmode=-1 on the kernel command line help? for the lockups at least.
Created attachment 464836 [details] more /var/log/messages from agpmode=-1 test Ran gltestperf again booted with radeon.agpmode=-1. This time the screen still did its flickering on and off thing, but instead of completing all the tests, the GUI mostly hung right after benchmark 2 started. The mouse would still move, but nothing was responsive. The system was not totally frozen though because I was able to get to a console with Ctrl-Alt-F2 and reboot. The attachment here is the /var/log/messages generated during that gltestperf run by running tail -f /var/log/messages > newmessages.txt just before starting gltestperf.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping