Attempting to track down radeon driver issue(s)?

Alex Deucher alexdeucher at
Tue May 5 12:13:55 PDT 2009

On Tue, May 5, 2009 at 3:11 PM, Lowell Alleman
<lowell at> wrote:
> On Tue, May 5, 2009 at 2:39 PM, Alex Deucher <alexdeucher at> wrote:
>> On Tue, May 5, 2009 at 2:34 PM, Martin Olsson <mnemo at> wrote:
>>> Alex Deucher wrote:
>>>> On Tue, May 5, 2009 at 12:28 PM, Lowell Alleman
>>>> <lowell at> wrote:
>>>>> I've got my X server stuck in some kind of loop that is using up nearly %100
>>>>> of the CPU.  I have a remote ssh connection and I'm running gdb against it.
>>>>> I've very unfamiar with debugging at this level, but I really want to
>>>>> anything I can to help track down some X issues I'm been hitting.
>>>> Your GPU has locked up.  The trick is finding what combination of
>>>> commands and state caused the lockup.
>>> If you had an intel gfx card and 2.6.30 kernel you could dump your batch
>>> buffers and see what command sequence caused it. I assume there is no such
>>> debugging facility for Radeon yet...
>> There are they are not upstream yet; only in Jerome's drm tree at the moment.
>> Alex
> Alex,
> Do you think this option is worth perusing?
> I'm in no way a kernel/X/driver developer; but I'm familiar with most
> linux admin tasks, building software from source and tracking down
> problems, and I'm willing to give it a try if you think there's a
> reasonable chance of this providing information that will help track
> down my issue.
> So this requires 2.6.30, and Jerome's drm tree?  (Can you point me to
> where this is?  Assuming this is a "git" tree, the command use to pull
> it would be quite helpful, since I'm more familiar with svn/bzr than
> git.)  Anything else required/recommended?

It's a whole kernel, plus you need updated libdrm, mesa, ddx.
Instructions for testing here:


More information about the xorg mailing list