[RV370] Xorg randomly freezes (100% CPU)

[Lev Kandel]

Binary package hint: xserver-xorg-video-ati

X started freezing once in a while after upgrading to Ubuntu 8.10. Now with 9.04 it's even more common.
Mouse pointer works, keyboard doesn't work, can ssh remotely. Attaching backtrace.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-ati 1:6.12.0-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersion: Linux version 2.6.28-11-generic (buildd@yellow) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #35-Ubuntu SMP Wed Mar 18 21:55:34 UTC 2009
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.28-11-generic x86_64

#0 0x00007f692368acd7 in ioctl () from /lib/libc.so.6
No symbol table info available.
#1 0x00007f69222cf343 in drmIoctl () from /usr/lib/libdrm.so.2
No symbol table info available.
#2 0x00007f69222cf646 in drmCommandNone () from /usr/lib/libdrm.so.2
No symbol table info available.
#3 0x00007f6921462d74 in RADEONDownloadFromScreenCP (
    pSrc=<value optimized out>, x=0, y=18, w=17, h=0, dst=0x9aa4ba0 "",
    dst_pitch=68) at ../../src/radeon_exa_funcs.c:411
 oldhpass = <value optimized out>
 i = 20984
 hpass = 0
 scratch_pitch_offset = 12060552
 indirect = {idx = 28090448, start = 50331648, end = 28363024,
  discard = 0}
 __head = <value optimized out>
 pScrn = (ScrnInfoPtr) 0x1aca050
 src = (uint8_t *) 0x7f690ebfa000 "\033\005"
 bpp = <value optimized out>
 datatype = 6
 src_pitch_offset = 11955556
 scratch_pitch = 128
 scratch_off = 0
 scratch = (drmBufPtr) 0x1b0cd30
#4 0x00007f6920ba3c49 in exaCopyDirty (migrate=0x7fff2dab0100,
    pValidDst=0x9a28e20, pValidSrc=<value optimized out>,
    transfer=0x7f69214627d0 <RADEONDownloadFromScreenCP>,
    fallback_src=0x7f691a6f3000 "\231\231\231", fallback_dst=0x9aa4ba0 "",
    fallback_srcpitch=128, fallback_dstpitch=68, fallback_index=1,
    sync=0x7f6920b9de10 <exaWaitSync>) at ../../exa/exa_migration.c:208
 pPixmap = (PixmapPtr) 0x9aa4b60
 pExaPixmap = (ExaPixmapPrivPtr) 0x9a28de0
 damage = <value optimized out>
 CopyReg = {extents = {x1 = 0, y1 = 0, x2 = 17, y2 = 18}, data = 0x0}
 save_offscreen = 1
 save_pitch = 128
 pBox = (BoxPtr) 0x7fff2daaff40
 nbox = 0
 access_prepared = 0
 need_sync = 0
 __func__ = "exaCopyDirty"
 firsttime = 0
#5 0x00007f6920ba3fc0 in exaDoMoveOutPixmap (migrate=0x7fff2dab0100)
    at ../../exa/exa_migration.c:256
 pPixmap = (PixmapPtr) 0x9aa4b60
#6 0x00007f6920ba46df in exaDoMigration (pixmaps=0x7fff2dab0100, npixmaps=1,
    can_accel=0) at ../../exa/exa_migration.c:677
 pExaScr = (ExaScreenPrivPtr) 0x1b0c910
 i = 1
 j = <value optimized out>
 __func__ = "exaDoMigration"

[lspci]
00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
     Subsystem: ABIT Computer Corp. Device [147b:1c0c]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV380 [Radeon X600 (PCIE)] [1002:5b62]
     Subsystem: ATI Technologies Inc Device [1002:0422]

[Bryce Harrington (bryce)]

I am not understanding your bug report. The title says that X is _freezing_, however you've attached a backtrace, which generally you only get if it _crashes_. Please explain in more detail what's going on with the bug and how you got the backtrace (thanks for getting it btw!)

[Lev Kandel (y5b2rqi02)]

X indeed freezes: no window updates, no response to mouse events (except that the cursor moves), no response to keyboard events (Caps Lock doesn't work, either). I got the backtrace by following the instructions at https://wiki.ubuntu.com/X/Backtracing, i.e., logged in remotely, ran gdb and attached to the Xorg process (which was consuming >100% CPU). Btw forgot to attach .xsession-errors, doing that now. Since reporting the bug, I've had this happen twice more. Both times, gdb showed Xorg to be stuck in exactly the same place. Attaching those (virtually identical) backtraces.

[Lev Kandel (y5b2rqi02)]

It just happened again; this time I turned on DRM debugging and let it run for a couple of minutes. syslog attached.

[Bryce Harrington (bryce)]

On Fri, Mar 20, 2009 at 02:30:55PM -0000, Lev Makhlis wrote:
> It just happened again; this time I turned on DRM debugging and let it
> run for a couple of minutes. syslog attached.
>
> ** Attachment added: "syslog"
> http://launchpadlibrarian.net/24150518/syslog

Hm, looks like something is wrong in the kernel's drm code for radeon.

Bryce

[Akkana Peck (akkzilla)]

This sounds like the same bug I filed as bug 347078 (I did try to search first, but didn't find this one for some reason). It's a jaunty showstopper for me because it can't go for more than a few hours without locking up (sometimes only a few minutes).

Same symptoms Lev describes: it will randomly start taking around 99% CPU, doesn't listen to any input except mouse movements -- no keyboard events or mouse clicks, but it can sort of follow mouse movements, with a lot of lag. The only fix is rebooting; Xorg isn't killable once this happens, even with -9.

On the other hand, my stack trace (if I ssh in from another box and attach to the Xorg process) is different from Lev's (it's attached in bug 347078).

Can I ask why this bug is marked incomplete? I don't see any pending requests, but I'd be happy to chime in with more system data if any is needed.

[Bryce Harrington (bryce)]

> Can I ask why this bug is marked incomplete? I don't see any pending requests, but I'd be happy to chime in with more system data if any is needed.

As I mentioned, it looks like perhaps this is a bug in drm code rather than in the -ati driver specifically. So the bug probably should be refiled against the linux kernel. Kernel bug reports need additional information in order to be considered complete; you can look at their bug reporting guidelines.

Akkana, if you're certain your bug is identical to this one, also please set it as a dupe of this one.

[Akkana Peck (akkzilla)]

I'm not certain -- the stack traces are different.

But I'm curious: I see it in my own locally built 2.6.28.7 kernel on Jaunty as well as in the standard Jaunty 2.6.28-5 kernel, but I don't see it under the exact same 2.6.28.7 kernel on Intrepid. If it was a kernel bug, shouldn't it happen in Intrepid too?

[Lev Kandel (y5b2rqi02)]

In my case it was happening in Intrepid, too. The difference is that in Intrepid, X would almost always lock up without increased CPU consumption, while in Jaunty it almost always locks up with 100+% CPU usage.

[Lev Kandel (y5b2rqi02)]

https://bugzilla.redhat.com/show_bug.cgi?id=462157 seems to be the same bug in Fedora. From the comments I gather that the jury is still out on whether it's an Xorg bug or a kernel bug. It also seems like it's currently closed, but never got fixed, which isn't encouraging.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

A new version of the -ati driver is now available in Karmic.

This is a significant update to -ati which brings in kernel mode-setting
(currently disabled) and scores of fixes for DRI2, EXA, etc.

I've posted the new version of this driver to the following PPA,
would you mind testing it and seeing if it resolves the bug you
reported?

  https://edge.launchpad.net/~bryceharrington/+archive/ppa/+sourcepub/709908/+listing-archive-extra

If you're not running this release of Ubuntu, you can try booting the Karmic
LiveCD and loading the PPA onto it, and then log out/in to restart X.
ISOs are available at http://cdimages.ubuntu.com/releases/

After testing Karmic, report back here whether it's still an issue or not,
and if it is please post a fresh Xorg.0.log and 'dmesg' output.

Note there could be new bugs... please file these as new reports using
the command 'ubuntu-bug xorg'.

[Lev Kandel (y5b2rqi02)]

No improvement. X freezes within a minute of login, and I couldn't even get it to work long enough to take a screenshot for bug 391439 until I used command line instead of the desktop menu. Attaching Xorg.0.log and dmesg output.

[Bryce Harrington (bryce)]

Thanks for testing; this should go upstream. Setting to Confirmed for now.

[Bryce Harrington (bryce)]

Forwarding this bug from Ubuntu reporter Lev Makhlis:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/345224

[Problem]
Xorg freezes with 100% CPU within a minute of login. Regression first appeared in Intrepid but is confirmed to still occur in Karmic with a recent -ati git snapshot.

[Original Description]
X started freezing once in a while after upgrading to Ubuntu 8.10. Now with 9.04 it's even more common.
Mouse pointer works, keyboard doesn't work, can ssh remotely. Attaching backtrace.

Architecture: amd64
DistroRelease: Ubuntu 9.04
Package: xserver-xorg-video-ati 1:6.12.0-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8ProcVersion: Linux version 2.6.28-11-generic (buildd@yellow) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #35-Ubuntu SMP Wed Mar 18 21:55:34 UTC 2009
SourcePackage: xserver-xorg-video-ati
Uname: Linux 2.6.28-11-generic x86_64

#0 0x00007f692368acd7 in ioctl () from /lib/libc.so.6
No symbol table info available.
#1 0x00007f69222cf343 in drmIoctl () from /usr/lib/libdrm.so.2
No symbol table info available.
#2 0x00007f69222cf646 in drmCommandNone () from /usr/lib/libdrm.so.2
No symbol table info available.
#3 0x00007f6921462d74 in RADEONDownloadFromScreenCP (
    pSrc=<value optimized out>, x=0, y=18, w=17, h=0, dst=0x9aa4ba0 "",
    dst_pitch=68) at ../../src/radeon_exa_funcs.c:411
 oldhpass = <value optimized out>
 i = 20984
 hpass = 0
 scratch_pitch_offset = 12060552
 indirect = {idx = 28090448, start = 50331648, end = 28363024,
  discard = 0}
 __head = <value optimized out>
 pScrn = (ScrnInfoPtr) 0x1aca050
 src = (uint8_t *) 0x7f690ebfa000 "\033\005"
 bpp = <value optimized out>
 datatype = 6
 src_pitch_offset = 11955556
 scratch_pitch = 128
 scratch_off = 0
 scratch = (drmBufPtr) 0x1b0cd30
#4 0x00007f6920ba3c49 in exaCopyDirty (migrate=0x7fff2dab0100,
    pValidDst=0x9a28e20, pValidSrc=<value optimized out>,
    transfer=0x7f69214627d0 <RADEONDownloadFromScreenCP>,
    fallback_src=0x7f691a6f3000 "\231\231\231", fallback_dst=0x9aa4ba0 "",
    fallback_srcpitch=128, fallback_dstpitch=68, fallback_index=1,
    sync=0x7f6920b9de10 <exaWaitSync>) at ../../exa/exa_migration.c:208
 pPixmap = (PixmapPtr) 0x9aa4b60
 pExaPixmap = (ExaPixmapPrivPtr) 0x9a28de0
 damage = <value optimized out>
 CopyReg = {extents = {x1 = 0, y1 = 0, x2 = 17, y2 = 18}, data = 0x0}
 save_offscreen = 1
 save_pitch = 128
 pBox = (BoxPtr) 0x7fff2daaff40
 nbox = 0
 access_prepared = 0
 need_sync = 0
 __func__ = "exaCopyDirty"
 firsttime = 0
#5 0x00007f6920ba3fc0 in exaDoMoveOutPixmap (migrate=0x7fff2dab0100)
    at ../../exa/exa_migration.c:256
 pPixmap = (PixmapPtr) 0x9aa4b60
#6 0x00007f6920ba46df in exaDoMigration (pixmaps=0x7fff2dab0100, npixmaps=1,
    can_accel=0) at ../../exa/exa_migration.c:677
 pExaScr = (ExaScreenPrivPtr) 0x1b0c910
 i = 1
 j = <value optimized out>
 __func__ = "exaDoMigration"

[lspci]
00:00.0 Memory controller [0580]: nVidia Corporation CK804 Memory Controller [10de:005e] (rev a3)
     Subsystem: ABIT Computer Corp. Device [147b:1c0c]
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV380 [Radeon X600 (PCIE)] [1002:5b62]
     Subsystem: ATI Technologies Inc Device [1002:0422]

[Bryce Harrington (bryce)]

Created an attachment (id=29129)
Xorg.0.log

[Bryce Harrington (bryce)]

Created an attachment (id=29130)
dmesg

[Bryce Harrington (bryce)]

Created an attachment (id=29131)
syslog

[Bryce Harrington (bryce)]

Created an attachment (id=29132)
gdb-Xorg-1.txt

[Bryce Harrington (bryce)]

Created an attachment (id=29133)
gdb-Xorg.txt

[agd5f (agd5f)]

please try with the latest git from master. make sure you have:
794ae743c305331741e7cf45dd71c755fe325ed5

[Bryce Harrington (bryce)]

Lev Makhlis - I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=23661 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

[Bryce Harrington (bryce)]

A Ubuntu package of 794ae743 can be found in this PPA for testing:

https://edge.launchpad.net/~xorg-edgers/+archive/ppa
 + xserver-xorg-video-ati - 1:6.12.99+git20090902.794ae743-0ubuntu0tormod

[93fy5qj02 (93fy5qj02)]

Tested the package above. So far there's no freeze after ~10 minutes of use. I'll keep it running and report back.

[93fy5qj02 (93fy5qj02)]

Took a little longer, but it still freezes :(

[Thomas-muehlfriedel (thomas-muehlfriedel)]

I see the exact same symptoms on my system since 8.10. Only that I am on 32 bit and Probed RADEON(0): Chipset: "ATI Radeon X800SE (R420) JJ (AGP)" (ChipID = 0x4a4a)
Why have there been no updates since september of last year? I can see that people most likely want to support the new cards rather than fixing stuff for the old ones but Linux has been pretty much unsable for me since the 'freezes' started to occur. Is there anything going to happen with this problem?

regards, tomsen

[agd5f (agd5f)]

Have you tried a newer radeon drm or newer version of xf86-video-ati?

[g-lock (kfm)]

I had this bug on my Radeon X700. When I set Option "Accel" "Off", the all works fine.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi Lev,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 345224

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 345224 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/345224

[Lev Kandel (y5b2rqi02)]

I haven't been able to reproduce the bug since replacing my graphics card with a different model. It seems likely that the root cause was hardware degradation, although I can't tell with certainty.

[Brian Murray (brian-murray)]

I've setting this bug to Invalid based off the reporter's comment that they no longer have the hardware and since it has received no comments from other people experiencing the same issue.