Attempting to track down radeon driver issue(s)?
lowell at allemansonline.com
Tue May 5 12:11:55 PDT 2009
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.
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?
More information about the xorg