Attempting to track down radeon driver issue(s)?

[Alex Deucher]

On Tue, May 5, 2009 at 3:11 PM, Lowell Alleman
<lowell at allemansonline.com> wrote:
> On Tue, May 5, 2009 at 2:39 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Tue, May 5, 2009 at 2:34 PM, Martin Olsson <mnemo at minimum.se> wrote:
>>> Alex Deucher wrote:
>>>> On Tue, May 5, 2009 at 12:28 PM, Lowell Alleman
>>>> <lowell at allemansonline.com> 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:
http://jglisse.livejournal.com/1822.html

Alex