Red Hat Bugzilla – Bug 472304
occasionally xorg takes up 100%CPU and unresponsive with XAA and nomodeset
Last modified: 2009-12-18 01:53:32 EST
Description of problem:
This is a spin-off of bug 462157 , where from time to time the xserver
takes up 100%CPU, mouse pointer still works but no response otherwise,
remote access works and and can be used to run gdb, or reboot.
Was asked to spit problem under XAA to a separate bug.
Version-Release number of selected component (if applicable):
once a couple of days.
Steps to Reproduce:
1. normal usage (web-browsing, etc, dragging windows about, etc).
xserver takes up 100% CPU, screen no longer updates (say, the system monitor applet's display no longer changes), mouse pointer still can be moved; remote access into the box from outside show the xerver using 100% CPU time.
See gdb backtrace with debug info in bug 462157 . There are quite a few of them.
It tends to show some data-copying via XAA get stuck at drm ioctl(). I hope the line-numbers, etc are useful to somebody.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 324172 [details]
xorg.conf with XAA
switch back to XAA for testing
Created attachment 324173 [details]
Xorg.0.log with XAA
Xorg.0.log with XAA
Created attachment 324174 [details]
Xorg.0.log when xorg.conf is renamed.
running without an xorg.conf
Created attachment 324175 [details]
Xorg.0.log when xorg.conf is renamed.with xorg-x11-drv-ati-6.9.0-55.fc10.
with xorg-x11-drv-ati-6.9.0-55.fc10. All the others were with xorg-x11-drv-ati-6.9.0-54.fc10. (just using a different VT, upgrade the rpm and then control-alt-backspace- should have upgraded first - there are some minor difference with attachment 324174 [details], which was with xorg-x11-drv-ati-6.9.0-54.fc10, just in case the difference is important).
Created attachment 324550 [details]
gdb backtrace with the latest of everything,when the x server gets stuck.
with the latest from koji:
Created attachment 324555 [details]
back trace, when stuck
stuck at different place from attachment 324550 [details] , same versions.
while changing gnome desktop background. (happened twice - looking at new f10 ones).
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
Created attachment 324819 [details]
gdb backtrce, with yet a newer ati_drv
This backtrace is probably similar to one of the earlier ones, but with a newer at-drv:
Yes, I have upgraded the rest of the system fully to f10 now...
Created attachment 325110 [details]
gdb backstrace, latest drv_ati, slightly different place.
with xorg-x11-drv-ati-6.9.0-60.fc10 , 184.108.40.206-130.fc10.x86_64 .
Created attachment 325137 [details]
another one very soon after the last one
another gdb backtrace, slight different, same versions of things as the last one
(and happened an hour after the last).
Created attachment 325323 [details]
gdb backtrace - more recent kernel
Created attachment 325552 [details]
Created attachment 325553 [details]
kernel-220.127.116.11-135.fc10 (newer kernel than the last)
Created attachment 325557 [details]
Created attachment 325746 [details]
Created attachment 326075 [details]
another backtrace with 18.104.22.168-137.fc10.x86_64
with the latest koji kernel
Created attachment 326079 [details]
more of the same...
Created attachment 326089 [details]
more of the same...
Created attachment 326506 [details]
more backtrace -
lately I seem to be able to trigger this at will by resizing an xpdf window. (I mean xpdf, not acroread nor evince nor kpdf nor okular).
I get this on i686 with EXA (no xorg.conf). I'm also using nomodeset. My wife keeps triggering it with facebook on firefox. I can trigger it instantly by attempting to move a gimp window.
I'm using the latest kernel and ati driver from testing.
My video card is an onboard RS690.
I've opened a new bug for this same issue using EXA as bug 479926.
This is still happening and my wife is getting really unhappy with it. It's repeatedly happening when she's typing a message on facebook.
#0 0x00110416 in __kernel_vsyscall ()
#1 0x00735979 in ioctl () from /lib/libc.so.6
#2 0x07bcf51d in drmDMA (fd=11, request=0xbfaf626c) at xf86drm.c:1228
#3 0x0033cfa7 in RADEONCPGetBuffer () from /usr/lib/xorg/modules/drivers//radeon_drv.so
#4 0x00346b30 in ?? () from /usr/lib/xorg/modules/drivers//radeon_drv.so
#5 0x00429e51 in XAAWritePixmapScanline (pScrn=0x904ea88, x=411, y=345, w=173, h=14, src=0x97aa3a8 "���", srcwidth=696,
rop=3, planemask=4294967295, trans=-1, bpp=32, depth=24) at xaaImage.c:356
#6 0x0041b721 in XAADoImageWrite (pSrc=0x97aa378, pDst=0x97a7b98, pGC=0x94ddbc8, prgnDst=0xbfaf6410, pptSrc=0x97a6fc0)
#7 0x0041ae72 in XAABitBlt (pSrcDrawable=0x97aa378, pDstDrawable=0x97a7b98, pGC=0x94ddbc8, srcx=0, srcy=0, width=174,
height=15, dstx=411, dsty=202, doBitBlt=0x41b600 <XAADoImageWrite>, bitPlane=0) at xaaBitBlt.c:203
#8 0x0041be0c in XAACopyArea (pSrcDrawable=0x97aa378, pDstDrawable=0x97a7b98, pGC=0x94ddbc8, srcx=0, srcy=0, width=174,
height=15, dstx=411, dsty=202) at xaaCpyArea.c:66
#9 0x0045c4b5 in cwCopyArea (pSrc=0x97aa378, pDst=0x97a7b98, pGC=0x94ddbc8, srcx=0, srcy=0, w=174, h=15, dstx=411,
dsty=202) at cw_ops.c:201
#10 0x08171792 in damageCopyArea (pSrc=0x97aa378, pDst=0x97a7b98, pGC=0x94ddbc8, srcx=0, srcy=0, width=174, height=15,
dstx=411, dsty=202) at damage.c:882
#11 0x08084179 in ProcCopyArea (client=0x91980d0) at dispatch.c:1581
#12 0x08085e9f in Dispatch () at dispatch.c:454
#13 0x0806b71d in main (argc=9, argv=0xbfaf66d4, envp=Cannot access memory at address 0xc0286431
) at main.c:441
strace gives the following three lines repeatedly:
ioctl(11, 0xc0286429, 0xbfaf61f4) = -1 EBUSY (Device or resource busy)
--- SIGALRM (Alarm clock) @ 0 (0) ---
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. 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 '10'.
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 10'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 10 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:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.