xorg/ radeonBuildHowTo
  1. Building new version from git
  2. Troubleshooting
  3. Reporting bugs

Building new version from git

It is possible to compile either stable or development version of radeon from git.

Changes to stable branch should be upgraded by distribution packages but in practice distributions don't follow the stable branch for released versions. If your distribution has failed to upgrade to the latest stable version you might get better stability by compiling new version from branch that matches your distribution version.

Development branch (master) is for bleeding edge development where you might get regression but also better performance and features. But if you decide that new features are worth the possible regression and bugs that happen in development you are more than welcome to upgrade to the latest code base. It is good idea to join our irc channel #radeon@freenode to get help for possible problems in bleeding edge code.

Stable branch

xf86-video-ati (ddx)

Upgrading to the latest bug fix code is simple because you don't have to upgrade only driver packages. First it is good idea to upgrade xf86-video-ati that provide 2D and mode setting code for xserver. You will need to clone the git repository from gitlab.freedesktop.org.

git clone https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati.git

Now you have cloned the git repository but code that was checked out is master branch which includes the bleeding edge code changes. Sometimes development is done in another specific GIT branch, you can check remote branches via:

git branch -r

You can easily switch to other branches (here: cayman_accel) or back to the master branch:

git checkout -b cayman_accel origin/cayman_accel
git checkout master

Now you have to solve build dependencies for the driver. Your package manager should have easy functionality for installing all the necessary packages. But for example there is:

apt-get build-dep xserver-xorg-video-ati (Debian/Ubuntu)
yum-builddep xorg-x11-drv-ati (Fedora)

Now you have to configure and build the code like any other program. It is good practice to install driver without overwriting files installed by package manager. This can be done using few configuration option. We want to install driver to a clean place where it is easy to remove in case you want to get rid of it.

./autogen.sh --prefix=/opt/xorg
make
sudo make install

Then you need to add configuration instruct xserver to load your self compiled driver. Adding following lines to xorg.conf will do the trick.

Section "Files"
        ModulePath "/opt/xorg/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection

Now restart your xserver and have fun with new bug fixes :)

Mesa3D

The Mesa3D library provides OpenGL with software and hardware rendering. There are also more libraries related to hardware accelerated graphics. Installing mesa to a location outside /usr is a bit more tricky. Problem here is that it is hard to make AIGLX load the dri driver from a non-system location.

There are multiple stable threads depending on your distribution so you should check your mesa version and renderer with glxinfo command.

glxinfo | grep ^OpenGL | egrep 'version|renderer'
OpenGL renderer string: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE2 TCL DRI2
OpenGL version string: 1.3 Mesa 7.11.1

Checkout mesa from GIT master branch ("clone" the entire repository):

git clone https://gitlab.freedesktop.org/mesa/mesa.git

cd mesa <--- Your local "copy" (your local GIT repository)

Branches were named mesa_X_Y_branch where X is major and Y minor number (nomenclature changed with creation of 7.8 GIT branch). Switch to a specific GIT branch (here: 7.11):

git checkout -b 7.11 origin/7.11

To see all GIT branches available, run 'git branch -r' within local GIT repository/branch.

Now you need again build dependencies which you should install for package libgl1-mesa-dri (See the example above). After you have installed all build dependencies we have to configure, build and install mesa. Prefix is again /opt/xorg for easy clean up if something goes wrong. You can of course use what ever you prefer. Example case enables all ATI drivers, but you would only need radeon, one of the specific drivers for your own card (r200, r300 or r600) and swrast for software fall back in case of problems with DRI or Gallium driver.

DRI_DRIVERS="radeon,r200"
GALLIUM_DRIVERS="r300,r600,swrast"
./autogen.sh --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --with-gallium-drivers=$GALLIUM_DRIVERS
make
sudo make install

HINT: Software rasterizer (swrast) dri driver is used as fallback solution.

Remember to read the instruction how to configure loading of new driver

Configuring system to load mesa and libdrm from /opt/xorg

Now comes the tricky part because you have to configure your system to load correct libraries when any application tries to load them. You have to configure ld to load first from /opt/xorg/lib so custom mesa libraries are loaded. Another tricky part is to load dri driver which requires environment variable set to point to /opt/xorg/lib/dri.

/etc/ld.so.conf.d/a-local-xorg.conf (new file) or add to begin of /etc/ld.so.conf if directory doesn't exists.

/opt/xorg/lib

and to /etc/environment you need to add new environment variable that tells libgl where to look for dri drivers (example r300_dri.so)

LIBGL_DRIVERS_PATH=/opt/xorg/lib/dri/

After changes to the files you have to run ldconfig as root to update the linker cache.

You can now test new dri driver in a terminal if you export LIBGL_DRIVERS_PATH. If everything works you can now restart to load new settings for all applications.

Problem with this configuration is that AIGLX doesn't respect it. This means that compiz doesn't get advantage of new driver.

It is possible to get the new libGL and dri drivers used without setting LIBGL_DRIVERS_PATH:

  • you need to build mesa with --with-dri-driverdir=/opt/xorg/lib/dri/ (or --with-dri-driverdir=/opt/xorg/lib/dri/ for 32-bit)
  • check that /opt/xorg takes precedence:
ldconfig -p | grep libGL.so
     libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so.1
     libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
     libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so
  • if system's libGL takes precedence it might be due to OS ABI, in that case build mesa with --enable-glx-tls

Before GettingStarted: Avoid known pitfalls

Distribution packages have often extra patches applied which might break compatibility with git sources. In that case you would have to get distro patches and apply them on top of source from git.

Checking for hardware 3D acceleration

glxinfo will give details about OpenGL rendering. Old fashioned guides for checking "direct rendering: Yes" are long outdated because swrast software rasterizer can do direct rendering.

glxinfo | grep OpenGL

Important part of output is renderer string that should read Mesa DRI 

OpenGL renderer string: Mesa DRI R200 (RV280 5C61) 20090101 x86/MMX+/3DNow!+/SSE TCL DRI2

While software will output:

OpenGL renderer string: Software Rasterizer

Removing AMD/ATI proprietary Linux display driver

You have to first remove fglrx because it overwrites our userspace files and conflicts with our kernel modules. Maybe some day drivers can coexists but not yet :/

First remove all fglrx packages and check that fglrx.ko is not left in /lib/modules/uname -r. If it is there you can just rm it and do depmod -a.

Next step is to reinstall mesa and libdrm. Which should be handled easily by your package manager or make install.

Last but not least is removing fglrx configurations from xorg.conf. With xserver 1.6 or higher you can just rename xorg.conf and trust the auto detect to do the right things.

Now you can reboot to clean system when open driver can function correctly.

For Debian systems:

apt-get update
apt-get install --reinstall libgl1-mesa-glx libgl1-mesa-dri <--- libGL.so + mesa3d DRI drivers

WARNING: The proprietary drivers from AMD/ATI and nVidia are known to overwrite Xserver extensions, for example GLX extension (libglx.so)!

apt-get install --reinstall xserver-xorg-core <--- libglx.so of xserver

Updating git tree

Updating git repository has two phases. First part is downloading changes and updating the history data for git. Second part is updating your local branch to match remote changes.

git fetch && git rebase origin

If you have any build problems after updating your source code run make clean and autogen.sh.

Removing self compiled driver

If you at any reason want to get rid of your self compiled driver it is simple as removing the configuration option from xorg.conf, /etc/ld.so.conf.d/ and environment. Then you can just restart computer and you are back at using the driver from package manager.

Removing the extra libraries is also easy with rm -r /opt/xorg.

Bleeding edge code from development branch

You will most likely have to upgrade a lot of stuff depending on how fresh your distro is. But minimum requirement is to have the latest xserver from the latest stable branch, latest stable kernel (some features might be only in rc kernels), libdrm master, mesa master and xf86-video-ati master.

Compiling and configuration is similar to stable branch with few exceptions.

  • You may have to configure libdrm with --enable-radeon-experimental-api (If your distribution enables it or you want to use KMS)
  • create /opt/xorg/share/aclocal
  • libdrm https://gitlab.freedesktop.org/mesa/drm/ has to be build and installed before mesa or ddx
  • You will need extra environment variables so configure script will find all self compiled dependencies
export PKG_CONFIG_PATH=/opt/xorg/lib/pkgconfig:/opt/xorg/share/pkgconfig
export LDFLAGS=-L/opt/xorg/lib CPPFLAGS=-I/opt/xorg/include
export ACLOCAL="/usr/bin/aclocal -I /opt/xorg/share/aclocal"

UPDATE: With libdrm >= 2.4.18 libdrm_radeon is built by default, now (configure-option --enable-radeon-experimental-api is obsolete).

[1] See commit 520c658706aa896d64f374cc74065394111f6122 "radeon: enable by default now that kms is out of staging".

Distro-specific development packages

Some distributions provide easy way to install development version of all required packages from single source. This makes beta testing a lot easier when you can get fresh packages without recompiling everything.

Kernel-based ModeSetting

Kernel-based ModeSetting (short: KMS) moves a lot of graphics card control logic to kernel which makes it possible to write more advanced 3D and 2D drivers. Kernel side mode setting improves VT switching and provides full resolution console.

KMS also moves DRI infrastructure to version 2 which will provide better performance for 3D drivers in future. But as always is case in large rewrite of basic infrastructure performance will go down at first because of missing features and not optimized code.

Current features in kernel side are

  • Mode setting
  • Memory management
  • Scheduling access to graphics card

After mode setting and memory management part has been finished there will be work to make dynamic power management work.

Prerequisites for radeon-KMS

For a better understanding of the correlation of all involved software components please have a closer look at Yang "yangman" Zhao's blog-article: "Linux Graphics Driver Stack Explained".

Basic and minimum requirements and recommendations (Update from 15-Apr-2012):

  • Linux-kernel r100-r500 >=2.6.32 | r600/r700 >=2.6.33 | evergreen >=2.6.34 (initial support) | latest-3.0: 3.0.28 | latest-3.2: 3.2.15 | latest-stable: 3.3.2
  • libdrm >=2.4.18 (minimum) | latest-stable: 2.4.33
  • mesa r100-r500 >=7.7.x | r600/r700 >=7.8.x | latest-7.11: 7.11.2 | latest-8.0: 8.0.2
  • ddx (aka xf86-video-ati) >=6.13.x | latest-stable: 6.14.4
  • xorg-server >=1.6.2 (minimum) | preferred >=1.7.x | latest-1.10: 1.10.6 | latest-1.11: 1.11.4 | latest-1.12: 1.12.1

NOTE-1: With Linux-2.6.33-rc6-git1 drm-radeon-kms has left staging driver area, see commit "drm/radeon/kms: move radeon KMS on/off switch out of staging.".

NOTE-2: For r600+ (r600 and higher) you might need extra firmware.

NOTE-3a: Initial evergreen 3D-acceleration support: For DDX see commit "Merge branch 'evergreen_accel' of git+ssh://git.freedesktop.org/git/xorg/driver/xf86-video-ati" and for Mesa see commit "r600g: add initial evergreen support"

NOTE-3b: Evergreen 3D-acceleration: Recommended: Linux-kernel >=2.6.38 + xf86-video-ati >=6.14.1 + mesa >=7.10.2 (r600 classic and gallium have 3D-acceleration whereas r600g is these days preferred)

NOTE-4: Linux v2.6.32.y and v3.0.y kernels have longterm support (LTS).

NOTE-5: Linux v3.2.y kernels will be shipped with upcoming Ubuntu 12.04 (LTS) and Debian wheezy (and maintained by Ubuntu/Debian kernel-teams).

NOTE-6: Experimental Trinity (TN) APU support: Linux-kernel >=3.4-rc1, latest-stable libdrm + ddx and mesa from Git master.

Important Linux kernel config parameters to enable radeon-KMS

CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_KMS=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FB_RADEON is not set

NOTE-1: A radeon kernel-module gives more flexibility (e.g. debug), for built-in solution change CONFIG_DRM_RADEON from "=m" to "=y".

NOTE-2: Disable old radeon framebuffer device, new is usage of kernel framebuffer device (fbcon) and radeondrmfb driver.

Packages to solve build dependencies

Unfortunately, it highly depends on your distribution on having all required development packages and libraries installed.

Solve build-deps using package-manager

The best (first) strategy is to solve the build dependencies using the distribution's package-manager.

For Debian distribution this would be:

apt-get build-dep libdrm                 <--- Userspace interface to kernel DRM services (development files, radeon-specific, etc.)
apt-get build-dep mesa                   <--- A free implementation of the OpenGL API (DRI modules, GLX runtime, GLX development files, etc.)
apt-get build-dep xserver-xorg-video-ati <--- X.Org X server -- AMD/ATI display driver
apt-get build-dep xorg-server            <--- Xorg X server (core server, development files, etc.)

Anyway, this might work or not. If the packages in the distribution's repository are too old, consult first your distro's support for help.

Other solutions that might help: For example in Debian there exists also an experimental distribution repository with latest software. In the worst case... There could be new stuff in the distro's own SCM (GIT or SVN) repositories, where you have to checkout and build by yourself.

Solve build-deps manually

That is really hard to say... It mostly depends on the freshness of your distribution and its included packages.

Here, the strategy would be to look into the configure* and Makefile* scripts and/or to start compiling each package and check for error-messages. This is no fun.

To make it a bit easier, we have a look into the build-order and into the build.sh script from xorg-devel (see [1]):

  1. macros
  2. protos
  3. libdrm (before ddx and mesa)
  4. ddx (aka xf86-video-ati)
  5. (mesa) <--- Optional, only if you want 3D-acceleration
  6. xserver

Again, within the diverse GIT repos there are explicitly depends on other development packages and/or libraries. You have to solve them first! Easiest way would be to check out and build via the recommended script from [1]. As GIT software is mostly Work-In-Progress, you might ran into other problems. A good orientation if the diverse components do build from GIT together is to look at the so-called "tinderbox" [2] (build failures are listed).

Another rough way is to check out from GIT and create missing packages in the distro's format (deb, rpm or whatever).

Please, also have a closer look at "Building the X Window System - The X.Org Modular Tree Developer's Guide" [3].

[1] https://gitlab.freedesktop.org/xorg/util/modular/-/blob/master/build.sh?ref_type=heads

[2] http://tinderbox.x.org/

[3] http://wiki.x.org/wiki/Building the X Window System

Experimental patches and development repositories

The kernel-related DRM development flow in Dave Airlie's linux GIT repository [1].

[1] http://cgit.freedesktop.org/~airlied/linux

List of active GIT branches in DRM kernel repository

Dave Airlie gives an overview over all the drm-related development GIT branches in his email "drm git branches revisited" to dri-devel mailing-list.

Dave decided to move to freedesktop GIT platform after suffered a security breach.

drm-next experimental branch

Especially drm-next GIT branch has the latest (experimental) stuff for radeon users.

Checkout drm-next GIT branch:

git clone git://people.freedesktop.org/~airlied/linux
cd linux
git checkout -b drm-next origin/drm-next

How to build kernel is not part of this guide because it is distribution specific. You should check your distribution documentations for guidance.

To be in "sync" with this experimental kernel, it is also recommended to have libdrm, mesa and ddx from GIT master.

Additional patches for reviewing and testing

Patches are sent to dri-devel and mesa3d-dev mailing-list (see [1] and [2]), before they are acknowledged and accepted in the diverse GIT branches.

[1] http://lists.freedesktop.org/archives/dri-devel/ [2] http://lists.freedesktop.org/archives/mesa-dev/

Troubleshooting

radeon-KMS issues

Module for frame buffer console

First of all check that you don't load radeonfb, uvesafb or vesafb module. This includes no vga parameters for kernel when using KMS. Console is provided by fbcon and radeondrmfb frame buffer console. So it is best to make sure that fbcon module is loaded.

Hints to dig deeper into radeon-KMS problems on startup

If you can't boot with KMS enabled the easiest way to debug problems is to boot into runlevel-3 (text console, VT) with KMS disabled or blacklist the radeon kernel-module. Then try to unload/load drm and radeon kernel-modules via modprobe commands (preferable over ssh and from a second machine).

Booted into runlevel-3 (grub-line: Append "radeon.modeset=0" means KMS disabled):

modprobe -r -v drm radeon    <--- Unload drm and radeon kernel-module (-r: remove, -v: verbose)
modprobe -v drm debug=1      <--- Additional for debugging DRM issues (maximum debug-level is 15)
modprobe -v radeon modeset=1 <--- Load radeon kernel-module with KMS support

NOTE-1: Depending on your distribution you have to use "radeon.modeset=0,1" (0: KMS disabled, 1: KMS enabled) or "nomodeset" and "modeset=1".

NOTE-2: Some distributions like Debian have no runlevel-3 defined, so blacklist the radeon kernel-module (or disable the start of graphical login-manager like kdm or gdm).

Check if radeon-KMS is enabled before X is started

First, make sure the radeon kernel-module is loaded with KMS enabled before X is started.

There are several possibilities to enable drm-radeon-kms on startup:

Append parameter to boot-menue

Append "radeon.modeset=1" as a parameter to grub/grub2 line (so called "Kernel command line").

Add to grub2 configuration

Use /etc/default/grub for this (edit file or run the echo-line below), followed by a renew of /boot/grub/grub.cfg (entries for boot-menue) via 'update-grub' command.

echo 'GRUB_CMDLINE_LINUX="radeon.modeset=1"' >> /etc/default/grub <--- or edit the file and change manually
update-grub

Activate via radeon.conf in /etc/modprobe.d directory

A good place to put persistent parameters for kernel-modules in general is /etc/modprobe.d directory, for radeon kernel-module use /etc/modprobe.d/radeon.conf.

cat /etc/modprobe.d/radeon-kms.conf
options radeon modeset=1

When KMS is not enabled before X is started, you might see the following error in your Xorg.log file (thanks TMM for providing a paste on IRC):

(EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
[dri] This chipset requires a kernel module version of 1.17.0,
[dri] but the kernel reports a version of 2.0.0.[dri] If using legacy modesetting, upgrade your kernel.
[dri] If using kernel modesetting, make sure your module is
[dri] loaded prior to starting X, and that this driver was built
[dri] with support for KMS.
[dri] Disabling DRI

radeon-KMS with AGP gfxcards

AGP gfxcards have a lot of problems so if you have one it is good idea to test PCI/PCIE mode using radeon.agpmode=-1. Another common solution to agp problems is disabling accelerated download from screen. You can see details with man exa how to do this.

Missing firmware

This is not a KMS problem, but people often report X does not start (thus it's included in the troubleshooting list). The real cause for this is the drm cannot find a missing radeon firmware (or microcode). This depends on the Linux-kernel version you use. To fix this issue simply install the package containing the radeon firmware files or consult your distribution's support.

dmesg | egrep -i 'firmware|microcode'

Check if your ddx and mesa-dri driver have KMS support

Your xf86-video-ati video-driver for X (the "DDX", 2D) doesn't have support for KMS? NO, then you have to rebuild it against libdrm_radeon library.

As a consequence this also means that you have to rebuild mesa against same new libdrm. Mesa-dri drivers (3D, accelerated) don't have KMS support without built against libdrm_radeon either.

Furthermore, check if you have fitting components of the Linux graphics driver stack.

sudo lsof | grep ^Xorg | egrep '_drv.so|_dri.so' | egrep 'radeon|r?00'
Xorg      19919        root  mem       REG        8,2    13107136     302055 /usr/lib/dri/r300_dri.so
Xorg      19919        root  mem       REG        8,2     1000892     554894 /usr/lib/xorg/modules/drivers/radeon_drv.so

sudo  egrep '_drv.so|_dri.so' /var/log/Xorg.0.log | egrep 'radeon|r?00'
(II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
(II) AIGLX: Loaded and initialized /usr/lib/dri/r300_dri.so

sudo ldd /usr/lib/dri/r?00_dri.so | grep radeon
        libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb7447000)

sudo ldd /usr/lib/xorg/modules/drivers/radeon_drv.so | grep radeon
        libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb75da000)

The output of ldd commands should clearly indicate a link to libdrm_radeon.

Missing Extra Firmware

All radeon gfxcards r600+ (r600 and higher) require extra firmware (ucode) files [1] to work properly with acceleration (Thanks agd5f for clarification on IRC). According to license issues [2] and the fact that no new firmware files will be shipped in upstream kernels, you need to activate the following kernel-config parameters:

CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/CYPRESS_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin radeon/R600_rlc.bin radeon/R700_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin"

You can omit those firmware files for which you do not actually have hardware. Copy *.bin to /lib/firmware/radeon directory.

UPDATE: Extra ucode files are now in linux-firmware GIT repository [3] (Thanks airlied for information on IRC).

[1] http://people.freedesktop.org/~agd5f/radeon_ucode/

[2] http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon

[3] See commit d9076a54d74e371a11e1206b4a26e2e428045b9e "radeon: add RLC firmwares from AMD."

Use 32-bit GL applications on 64-bit systems

32-bit applications (such as wine) will need a 32-bit libGL and mesa dri drivers. If you've only built the 64-bit libraries, your 32-bit apps may still be using the distro provided 32-bit libGL and dri (if you have already installed them), which will probably just result in slowness and wrong image being displayed.

To make 32-bit apps use the new driver (the examples below show 64-bit libs installed in /lib (Debian), your distro may install to /lib64 instead (Fedora and others):

  • build libdrm from git (here for Debian 64-bit, Info: The original libdrm libs from ia32-libs package will be replaced):
./autogen.sh --prefix=/usr --libdir=/usr/lib32 CFLAGS="-m32 -O2 -g"
  • build mesa as 32-bit:
DRI_DRIVERS="radeon,r200,r300,r600,swrast"
DRI_DRIVER_DIR="/opt/xorg/lib32/dri"
./autogen.sh --prefix=/opt/xorg --with-dri-drivers=$DRI_DRIVERS --with-dri-driverdir=$DRI_DRIVER_DIR --enable-32-bit --libdir=/opt/xorg/lib32 --disable-gallium --enable-glx-tls
make
sudo make install
  • Run ldconfig to update dynamic linker run-time bindings:
sudo ldconfig
  • Check that the desired libGL is used - libGL from /opt/xorg should be first in all cases:
sudo ldconfig -p | grep libGL.so
      libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so.1
      libGL.so.1 (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/libGL.so.1
      libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /opt/xorg/lib32/libGL.so.1
      libGL.so.1 (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so.1
      libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /opt/xorg/lib/libGL.so
      libGL.so (libc6, OS ABI: Linux 2.4.20) => /opt/xorg/lib32/libGL.so
      libGL.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so
  • Check that the new 32-bit (mesa) dri driver is loaded:
$mesa32-builddir/progs/xdemos/glxinfo | grep OpenGL
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV730 9498) 20090101 x86/MMX/SSE2 TCL DRI2
OpenGL version string: 2.0 Mesa 7.8-devel
OpenGL shading language version string: 1.10
OpenGL extensions:

radeon-KMS power-management

Linux-kernel >=2.6.35 has now power-management code for radeon gfxcards R100-R700 (see [1]).

NOTE: Linux-kernel(s) from upstream or drm-next GIT branch might have better support (WIP).

Change power-management method

There exist two basic power-management (short: PM) methods "dynpm" and "profile" set via sysfs:

echo "dynpm" > /sys/class/drm/card0/device/power_method
or
echo "profile" > /sys/class/drm/card0/device/power_method

cat /sys/class/drm/card0/device/power_method
profile

The "profile" method exposes 4 profiles that can be selected from: 1. "default" 2. "auto" 3. "low" 4. "high" In the meantime there has been a 5th "mid" profile introduced (see [2]).

How to get/select the PM profile method?

cat /sys/class/drm/card0/device/power_profile
default
echo "low" > /sys/class/drm/card0/device/power_profile

WARNING: !!! the low power management setting does not work properly with displays active on some laptops !!!

NOTE: See also KMS Power Management Options

[1] http://lists.freedesktop.org/archives/dri-devel/2010-May/000492.html [2] http://www.spinics.net/lists/dri-devel/msg01028.html

Reporting bugs

If problem is 3D relate correct place to report it is https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa.

Because driver is split between DDX and Mesa all 2D and xv related problems should be reported to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg.

You should include xorg.log and dmesg at minimum. Also exact steps to reproduce the problem will help a lot in solving the problem. Any extra debugging info you have gathered is welcome too. Please select text/plain mime type for any text attachments so they are easier to read.

Debug symbols are important when submitting backtraces so you should take little bit time to install them. There is usually easy way to install them from distribution provided packages. Minimum for debug symbols is mesa, ddx and xorg core to give easily readable backtraces.