Bug 498278

Created attachment 341800 [details]
Xorg.0.log

Created attachment 341801 [details]
/var/log/messages

Created attachment 341802 [details]
dmesg output

Created attachment 342585 [details]
Xorg.0.log (KMS, no xorg.conf)

Still have the problem with these:

xorg-x11-server-1.6.1-11.fc11.i586.rpm
xorg-x11-drv-ati-6.12.2-11.fc11.i586.rpm
kernel-2.6.29.2-126.fc11.i686.PAE

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:

^C
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
Continuing.

Created attachment 342586 [details]
Xorg.0.log (nomodeset, no xorg.conf)

Same symptoms with "nomodeset"

xorg-x11-server-1.6.1-11.fc11.i586.rpm
xorg-x11-drv-ati-6.12.2-11.fc11.i586.rpm
kernel-2.6.29.2-126.fc11.i686.PAE

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) 
(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, 
    h=900, 
    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---
*\377J4)\377M7,\377R<1\377S=2\377N8-\377L6+\377N8-\377O9.\377O9.\377M7,\377Q;0\377P:/\377P8.\377P7-\377S:0\377T;1\377U<2\377S=1\377U?3\377U?3\377R<0\377R<0\377V@4\377WA5\377T>2\377N8,\377Q;/\377N8,\377M7+\377P8-\377S:0\377W?4\377Y@4\377[A5\377Z@4\377R8,\377P8,\377O9-\377R<0\377R?2\377N<0\377I7,\377"..., 
    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
(gdb)

can you try booting with radeon.agpmode=1 on the kernel command line?

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.

nomodeset + XAA gets me a usable X server, but it has other issues of hanging after some use.

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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.]

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]

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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Improving summary.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]

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.)