Bug 583319 - KMS:RV280:9200 GPU lockup
Summary: KMS:RV280:9200 GPU lockup
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 14
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-17 20:44 UTC by Tom Horsley
Modified: 2018-04-11 09:38 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 18:22:40 UTC
Type: ---


Attachments (Terms of Use)
Xorg.0.log (67.16 KB, text/plain)
2010-04-17 20:51 UTC, Tom Horsley
no flags Details
/var/log/dmesg (24.48 KB, text/plain)
2010-04-17 20:52 UTC, Tom Horsley
no flags Details
/var/log/messages (512.05 KB, text/plain)
2010-04-17 20:53 UTC, Tom Horsley
no flags Details
screenshot from bad display (61.45 KB, image/jpeg)
2010-05-10 00:52 UTC, Tom Horsley
no flags Details
screenshot from working fedora 13 system (69.83 KB, image/jpeg)
2010-05-10 00:54 UTC, Tom Horsley
no flags Details
selected radeon entries from /var/log/messages (470.10 KB, text/plain)
2010-06-04 01:33 UTC, Nivag
no flags Details
/var/log/message to go with comment 15 (385.16 KB, text/plain)
2010-12-04 20:27 UTC, Tom Horsley
no flags Details
more /var/log/messages from agpmode=-1 test (60.59 KB, text/plain)
2010-12-05 13:14 UTC, Tom Horsley
no flags Details

Description Tom Horsley 2010-04-17 20:44:57 UTC
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:

Comment 1 Tom Horsley 2010-04-17 20:51:30 UTC
Created attachment 407311 [details]
Xorg.0.log

Comment 2 Tom Horsley 2010-04-17 20:52:23 UTC
Created attachment 407312 [details]
/var/log/dmesg

Comment 3 Tom Horsley 2010-04-17 20:53:52 UTC
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 :-).

Comment 4 Tom Horsley 2010-05-10 00:52:40 UTC
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.

Comment 5 Tom Horsley 2010-05-10 00:54:20 UTC
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.

Comment 6 Nivag 2010-06-04 01:29:59 UTC
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

Comment 7 Nivag 2010-06-04 01:33:37 UTC
Created attachment 421084 [details]
selected radeon entries from /var/log/messages

Comment 8 Nivag 2010-06-04 01:37:13 UTC
# 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

Comment 9 Matěj Cepl 2010-06-07 20:09:40 UTC
(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.

Comment 10 Tom Horsley 2010-06-07 20:51:39 UTC
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.

Comment 11 Kjeld Flarup 2010-06-13 20:19:24 UTC
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

Comment 12 Nivag 2010-07-07 01:23:10 UTC
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.)

Comment 13 Tom Horsley 2010-10-09 02:10:55 UTC
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

Comment 14 Dave Airlie 2010-12-04 07:53:49 UTC
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/

Comment 15 Tom Horsley 2010-12-04 20:25:27 UTC
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.

Comment 16 Tom Horsley 2010-12-04 20:27:42 UTC
Created attachment 464777 [details]
/var/log/message to go with comment 15

Gazillions of radeon related kernel walkbacks at the end of this file.

Comment 17 Dave Airlie 2010-12-05 07:42:11 UTC
does booting with radeon.agpmode=-1 on the kernel command line help?

for the lockups at least.

Comment 18 Tom Horsley 2010-12-05 13:14:38 UTC
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.

Comment 19 Fedora End Of Life 2012-08-16 18:22:43 UTC
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


Note You need to log in before you can comment on or make changes to this bug.