Bug 498278 - KMS:R300:Radeon 9500 Pro black screen (EXA hang)
KMS:R300:Radeon 9500 Pro black screen (EXA hang)
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-04-29 13:40 EDT by Charles R. Anderson
Modified: 2010-05-24 13:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-24 13:59:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (43.26 KB, text/plain)
2009-04-29 13:44 EDT, Charles R. Anderson
no flags Details
/var/log/messages (106.97 KB, text/plain)
2009-04-29 13:47 EDT, Charles R. Anderson
no flags Details
dmesg output (31.50 KB, text/plain)
2009-04-29 13:48 EDT, Charles R. Anderson
no flags Details
Xorg.0.log (KMS, no xorg.conf) (43.26 KB, text/plain)
2009-05-05 23:23 EDT, Charles R. Anderson
no flags Details
Xorg.0.log (nomodeset, no xorg.conf) (62.58 KB, text/plain)
2009-05-05 23:41 EDT, Charles R. Anderson
no flags Details

  None (edit)
Description Charles R. Anderson 2009-04-29 13:40:02 EDT
Description of problem:

Booting up with KMS shows correct graphical plymouth splash screen.  Once X starts up, the image either doesn't change from the plymouth splash, or it goes all black.  In either case, the correct mouse cursor appears and can be moved around with the mouse.  Booting into runlevel 3, the screen is correctly initialized to a high resolution text mode.  From there, "telinit 5" turns the screen all black with a mouse cursor that moves around, but nothing else appears.

This is on an ATI Technologies Inc R300 AD [Radeon 9500 Pro].  The same problem has existed on F11-Beta, F11-Preview, and the latest rawhide updates as indicated below.  The system had to be installed using VNC.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. boot any recent LiveCD or latest rawhide to runlevel 5
2. boot latest rawhide to runlevel 3, the "telinit 5"
Comment 1 Charles R. Anderson 2009-04-29 13:44:43 EDT
Created attachment 341800 [details]
Comment 2 Charles R. Anderson 2009-04-29 13:47:24 EDT
Created attachment 341801 [details]
Comment 3 Charles R. Anderson 2009-04-29 13:48:18 EDT
Created attachment 341802 [details]
dmesg output
Comment 4 Charles R. Anderson 2009-05-05 23:23:22 EDT
Created attachment 342585 [details]
Xorg.0.log (KMS, no xorg.conf)

Still have the problem with these:


dmesg | grep drm

[drm] Initialized drm 1.1.0 20060810
[drm] Forcing AGP to PCI mode
[drm] Detected VRAM RAM=131072K, accessible=131072K, BAR=131072K
[drm] Default TV standard: NTSC
[drm] 27.000000000 MHz TV ref clk
[drm] DFP table revision: 4
fbcon: radeondrmfb (fb0) is primary device
[drm] TMDS-8: set mode 1600x1200 16
fb0: radeondrmfb frame buffer device
[drm] Loading R300 Microcode
[drm] Num pipes: 2
[drm] writeback test succeeded in 1 usecs
[drm] Initialized radeon 1.29.0 20080528 for 0000:01:00.0 on minor 0

Backtrace from gdb while screen is black:

Program received signal SIGINT, Interrupt.
0x00b6e416 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 1 (Thread 0xb7fcb730 (LWP 2180)):
#0  0x00b6e416 in __kernel_vsyscall ()
#1  0x01068b89 in ioctl () from /lib/libc.so.6
#2  0x008227ad in drmIoctl (fd=8, request=3222037603, arg=0xbfadda74)
    at xf86drm.c:187
#3  0x00822a9b in drmCommandWriteRead (fd=8, drmCommandIndex=35, 
    data=0xbfadda74, size=12) at xf86drm.c:2363
#4  0x0062b02e in radeon_bufmgr_gem_force_map (buf=0x913e8f8)
    at radeon_bufmgr_gem.c:254
#5  0x0061129a in RADEONPrepareAccess (pPix=0x913e7e0, index=1)
    at radeon_exa.c:277
#6  0x003b93ab in ExaDoPrepareAccess (pDrawable=0x913e7e0, index=1)
    at exa.c:517
#7  0x003b94ac in exaPrepareAccessReg (pDrawable=0x913e7e0, index=1, pReg=0x0)
    at exa.c:537
#8  0x003b94ec in exaPrepareAccess (pDrawable=0x913e7e0, index=1) at exa.c:549
#9  0x003b9666 in exaChangeWindowAttributes (pWin=0x90981e0, mask=1)
    at exa.c:682
#10 0x0813f20f in compChangeWindowAttributes (pWin=0x90981e0, mask=1)
    at compinit.c:115
#11 0x08073469 in ChangeWindowAttributes (pWin=0x90981e0, vmask=1, 
    vlist=0x917e330, client=0x91316c0) at window.c:1455
---Type <return> to continue, or q <return> to quit---
#12 0x08086315 in ProcChangeWindowAttributes (client=0x91316c0)
    at dispatch.c:538
#13 0x080867f7 in Dispatch () at dispatch.c:437
#14 0x0806bb0d in main (argc=8, argv=0xbfadde84, envp=0xbfaddea8) at main.c:397
(gdb) cont
Comment 5 Charles R. Anderson 2009-05-05 23:41:59 EDT
Created attachment 342586 [details]
Xorg.0.log (nomodeset, no xorg.conf)

Same symptoms with "nomodeset"


Different backtrace with "nomodeset".  The bt is always the same whenever I hit "ctrl-c" in gdb (that is also true for the KMS case, but with a different bt there).  Is R300 using EXA even with KMS?  I thought UXA was in use with KMS...

0x0080d416 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 1 (Thread 0xb801d730 (LWP 2181)):
#0  0x0080d416 in __kernel_vsyscall ()
#1  0x00375b89 in ioctl () from /lib/libc.so.6
#2  0x0025273d in drmDMA (fd=10, request=0xbfb2fe60) at xf86drm.c:1229
#3  0x00651428 in RADEONCPGetBuffer (pScrn=0x94a7160) at radeon_accel.c:774
#4  0x006517d1 in RADEONCPFlushIndirect (pScrn=0x94a7160, discard=1)
    at radeon_accel.c:849
#5  0x00655b26 in RADEONHostDataBlit (pScrn=0x94a7160, cpp=4, w=1600, 
    dstPitchOff=423470696, bufPitch=0xbfb2ffe8, x=0, y=0xbfb30018, 
    h=0xbfb30020, hpass=0xbfb2ffec) at radeon_accel.c:994
#6  0x006af755 in RADEONUploadToScreenCP (pDst=0xa3080008, x=0, y=300, w=1600, 
    src=0xa3254c38 "^B1\377bF4\377dH7\377cG6\377`D3\377]A0\377[?.\377Y=,\377Y=,\377X<+\377Y=,\377^B1\377]C2\377W>.\377W=,\377Z@/\377]C2\377^C2\377\\@/\377Y=,\377Y=,\377Y=,\377W=,\377X>-\377X>.\377W=-\377X>.\377X>.\377V<,\377V<,\377Z@0\377[A0\377\\B1\377\\B1\377[A0\377Z@/\377Y?.\377Y?.\377X=,\377Y?.\377]C2\377Z@/\377W=,\377Z@/\377\\B2\377^D4\377^D4\377Y?/\377U;+\377T:*\377"..., src_pitch=6400)
    at radeon_exa_funcs.c:430
#7  0x005a5e24 in exaCopyDirty (migrate=<value optimized out>, 
    pValidDst=<value optimized out>, pValidSrc=0x9551a68, 
    transfer=0x6af2d0 <RADEONUploadToScreenCP>, 
    fallback_src=0xa3080038 "L8-\377L8-\377K7,\377I5*\377K7,\377N8-\377L6+\377K5---Type <return> to continue, or q <return> to quit---
    fallback_dst=0xb6835000 "\377\377\377\377\377\377\377\377\377\377\337\377\377\377\377\377\377\377\377\337\377\276\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\337\377\377\373\377\377\377\373\377\375\377\377\377\377\277\377\357\357\377\377\377\377\377\377\277\377\177\377\377\377\373\377\377\337\377\377\377\377\377\357\377\377\377\377\377\377\377\377\377\377\377\377\377\375\377\177\377\376\377\377\377\367\377\377\357\377\377\375\377\375\377\377\375\377\377\377\377\377\377\337\377\377\377\377\377\377\377\357\377\377\353\377\377\377\377\377\337\356\377\377\267\377\377\367\375\377\377\377\377\373\377\377\377\377\377\377\377\377\377\377\377\377\177\377\377\377\377\377\375\377\377\377\377\377\377\377\337\377\377\377\377\377\377\377\377\376\377\377\377\377\377\377\377\337\377\357\377\373\377\377"..., fallback_srcpitch=6400, 
    fallback_dstpitch=6400, fallback_index=0, sync=0x59ff80 <exaMarkSync>)
    at exa_migration.c:208
#8  0x005a6450 in exaCopyDirtyToFb (migrate=<value optimized out>)
    at exa_migration.c:274
#9  exaDoMoveInPixmap (migrate=<value optimized out>) at exa_migration.c:333
#10 0x005a6bca in exaDoMigration (pixmaps=0xbfb30210, npixmaps=2, can_accel=1)
    at exa_migration.c:683
#11 0x005a3bfc in exaCopyNtoN (pSrcDrawable=0xa3080008, 
---Type <return> to continue, or q <return> to quit---
    pDstDrawable=0xa28cc008, pGC=0x0, pbox=0xbfb3033c, nbox=1, dx=0, dy=0, 
    reverse=0, upsidedown=0, bitplane=0, closure=0x0) at exa_accel.c:479
#12 0x005a8cea in exaComposite (op=1 '\1', pSrc=0x95f1d68, pMask=0x0, 
    pDst=0x95ee4d0, xSrc=0, ySrc=0, xMask=<value optimized out>, 
    yMask=<value optimized out>, xDst=0, yDst=0, width=1600, height=1200)
    at exa_render.c:865
#13 0x081786fb in damageComposite (op=216 '\330', pSrc=0x95f1d68, pMask=0x0, 
    pDst=0x95ee4d0, xSrc=<value optimized out>, ySrc=<value optimized out>, 
    xMask=<value optimized out>, yMask=<value optimized out>, 
    xDst=<value optimized out>, yDst=<value optimized out>, 
    width=<value optimized out>, height=<value optimized out>) at damage.c:643
#14 0x0816a8cc in CompositePicture (op=1 '\1', pSrc=0x95f1d68, pMask=0x0, 
    pDst=0x95ee4d0, xSrc=0, ySrc=0, xMask=<value optimized out>, 
    yMask=<value optimized out>, xDst=<value optimized out>, 
    yDst=<value optimized out>, width=1600, height=1200) at picture.c:1675
#15 0x0817081b in ProcRenderComposite (client=0x958d010) at render.c:720
#16 0x0816d4c5 in ProcRenderDispatch (client=0xbfb2fdd8) at render.c:2086
#17 0x080867f7 in Dispatch () at dispatch.c:437
#18 0x0806bb0d in main (argc=8, argv=0xbfb30674, envp=0xbfb30698) at main.c:397
Comment 6 Dave Airlie 2009-05-06 01:02:44 EDT
can you try booting with radeon.agpmode=1 on the kernel command line?
Comment 7 Charles R. Anderson 2009-05-06 10:15:36 EDT
radeon.agpmode=1 isn't accepted by drm.  It says that only 4 or 8 are supported, and it defaults to 8 so I tried 4.  The symptoms are the same with either kms or nomodeset--black screen with movable mouse cursor, cursor animation works too.

There are no appreciable differences in kernel messages or Xorg.0.log output for these attempts.
Comment 8 Charles R. Anderson 2009-05-27 19:21:34 EDT
nomodeset + XAA gets me a usable X server, but it has other issues of hanging after some use.
Comment 9 Bug Zapper 2009-06-09 10:48:26 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 10 Matěj Cepl 2009-11-05 13:27:47 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 11 Matěj Cepl 2010-02-26 07:14:15 EST
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Comment 12 Bug Zapper 2010-04-27 10:00:13 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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: 
Comment 13 Vedran Miletić 2010-05-24 13:40:52 EDT
Improving summary.


Fedora Bugzappers volunteer triage team

[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]
Comment 14 Charles R. Anderson 2010-05-24 13:59:44 EDT
I'm closing this NOTABUG because eventually the system power supply completely failed.  After replacing the power supply, I am now using a Radeon 9800 Pro and I'm not having this issue with that card (Fedora 11, no xorg.conf, KMS).  I haven't gone back and tried the Radeon 9500 Pro, but I suspect the problems I was having were due to the marginal/failing power supply.  (I'm still having random screen blanking issues though, usually during scrolling, video playback, and other display intensive tasks.  I'm wondering if the 250W power supply is underpowered for this card.)

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