Bug 28375

Created attachment 36046 [details]
dmesg with WARNING no. 1

Most important part:
[  512.026242] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x236/0x290 [radeon]()

Backtrace quite useless :|
[  512.026794]  [<fac7a34d>] drm_ioctl+0x12d/0x350 [drm]
[  512.026919]  [<fac7a220>] ? drm_ioctl+0x0/0x350 [drm]

Created attachment 36047 [details]
dmesg with WARNING no. 2

Most important part:
[  743.244277] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x236/0x290 [radeon]()

Backtrace quite useless :|
[  743.244819]  [<fac7a34d>] drm_ioctl+0x12d/0x350 [drm]
[  743.244929]  [<fac7a220>] ? drm_ioctl+0x0/0x350 [drm]

Created attachment 36048 [details]
dmesg with WARNING no. 3 (with drm:drm_ioctl)

In previous dmesgs I disabled drm:drm_ioctl debugging. This one keeps that debugging enabled.

Most important part:
[  101.033181] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x236/0x290 [radeon]()

Backtrace quite useless :|
[  101.033712]  [<fac7d3c2>] drm_ioctl+0x1a2/0x3f0 [drm]
[  101.033828]  [<fac7d220>] ? drm_ioctl+0x0/0x3f0 [drm]

Also are you using the ddx tiling patches?  If so, do you get the same lock up with those removed?  This might be a dupe of bug 28342.

Created attachment 36049 [details]
dmesg with GPU lockup CP stall detected no. 1

Created attachment 36050 [details]
dmesg with GPU lockup CP stall detected no. 2

Created attachment 36051 [details]
dmesg with GPU lockup CP stall detected no. 3

Created attachment 36052 [details]
Xorg.0.log

(In reply to comment #4)
> Also are you using the ddx tiling patches?  If so, do you get the same lock up
> with those removed?  This might be a dupe of bug 28342.

Today's drm-radeon-testing means:

commit 9e67e5b1a6fd4bdca48a9c267386afb236d08783
Merge: b55ad86 e40152e
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Jun 1 13:04:52 2010 +1000

    Merge tag 'v2.6.34' into drm-radeon-testing



As for DDX I use quite old one:

commit 488c9fd8300505cc6c0c2f8f0f00849f27cc5d63
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Mon Mar 15 12:25:57 2010 -0400

    r6xx/r7xx: fix domain handling in accel code

    Noticed by Pauli and Michel on IRC.

    Improves GetImage performace by a factor of ~10.


Let me try updating it.

Ohh, that was silly. I didn't understand why first 3 dmesgs are so meaningless... I grepped them for "drm"! :|

Before updating xf86-video-ati I tried patch from attachment #36012 [details] [review] but it does not help.

Updating DDX didn't help. I gone back with drm tree to:

commit 94f2983b1dc64a4a90a1ac9a6da6d7a0ec2f06a8
Author: Tiago Vignatti <tiago.vignatti@nokia.com>
Date:   Mon May 24 18:24:31 2010 +0300

    vgaarb: use MIT license

which seems to be one commit before first tiling patches. It also has problems I described in this bug report.

As I didn't apply any patches to DDX manually, I guess there is nothing I can revert, right?

 bad: 94f2983b1dc64a4a90a1ac9a6da6d7a0ec2f06a8
good: 36d1701c502d4f46386e1000ad58d9497a11688d

Suspected commits:
drm/radeon/kms/pm: add support for SetVoltage cmd table (V2)
drm/radeon/kms/pm: voltage fixes
drm/radeon/kms/pm: radeon_set_power_state fixes
drm/radeon/kms/pm: patch default power state with default clocks/voltages on r6xx+

If I had to guess, I would say:
drm/radeon/kms/pm: add support for SetVoltage cmd table (V2)

Changing the voltage could be problematic on your card.  We should probably step up/down the voltage rather than changing it directly.  E.g., when going from 1200 to 900 millivolts, step down to 1100, 1000, then 900.  I'll see about hacking something up tomorrow if you can verify that is the problematic commit.

Created attachment 36057 [details] [review]
step through voltage levels

If the SetVoltage stuff is indeed causing problems, this patch might help.

I can confirm it's voltage setting that causes problem. Dropping it from r600.c::r600_pm_misc makes d-r-t work again.

I didn't test your patch Alex, but it does not make much sense in my case.

1) Looking through all power modes I noticed only 2 different voltages: 950 and 1200.
2) Step is 250 anyway: 0018: USHORT usVoltageStep = 0x00fa (250)

Created attachment 36081 [details]
less revoltaging and more deubgging messages

Created attachment 36082 [details]
dmesg with less revoltaging patch applied

There you have some results of my debugging tries.

Voltage was changed at 86.386427 and it didn't cause any problem. When starting glxgears I expected voltage to be raised but it wasn't the case. Maybe this is the problem?

Patch posted:

[PATCH V3] drm/radeon/kms/r600+: use voltage from requested clock mode
http://lists.freedesktop.org/archives/dri-devel/2010-June/001139.html