Bug 25580 - [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout
Summary: [REGRESSION] drm/radeon/kms: [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0...
Status: RESOLVED DUPLICATE of bug 25567
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2009-12-11 00:33 UTC by Rafał Miłecki
Modified: 2009-12-15 14:22 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

dmesg from starting X (89.90 KB, text/plain)
2009-12-11 00:34 UTC, Rafał Miłecki
no flags Details
git bisect log (2.23 KB, text/plain)
2009-12-11 09:49 UTC, Rafał Miłecki
no flags Details
results of manual bisecting (1.82 KB, text/plain)
2009-12-12 01:08 UTC, Rafał Miłecki
no flags Details
patch that *does not* fix problem (854 bytes, text/plain)
2009-12-12 03:23 UTC, Rafał Miłecki
no flags Details
patch that *does not* fix problem (658 bytes, text/plain)
2009-12-12 03:23 UTC, Rafał Miłecki
no flags Details
patch that *does* fix problem (870 bytes, patch)
2009-12-12 03:23 UTC, Rafał Miłecki
no flags Details | Splinter Review

Description Rafał Miłecki 2009-12-11 00:33:24 UTC
Day after splitting branches by Dave I switched to drm-radeon-testing and was using it successfully. Yesterday I did pull last changes and now my machine locks up in 70% tries of starting X.

Unfortunately I did "dmegs > dmesg.log" so I didn't catch messages before netconsole loading... Are attached messages enough?

M82 == RV620
Comment 1 Rafał Miłecki 2009-12-11 00:34:49 UTC
Created attachment 31970 [details]
dmesg from starting X

[   44.039173] [drm:radeon_fence_wait] *ERROR* fence(f6608d80:0x00000007) 510ms timeout going to reset GPU
[   44.039200] radeon 0000:01:00.0: GPU softreset 
[   44.039220] radeon 0000:01:00.0:   R_008010_GRBM_STATUS=0xA0003030
[   44.039242] radeon 0000:01:00.0:   R_008014_GRBM_STATUS2=0x00000003
[   44.039263] radeon 0000:01:00.0:   R_000E50_SRBM_STATUS=0x200000C0
[   44.039289] radeon 0000:01:00.0:   R_008020_GRBM_SOFT_RESET=0x00007FEE
[   44.039360] radeon 0000:01:00.0: R_008020_GRBM_SOFT_RESET=0x00000001
[   44.039446] radeon 0000:01:00.0:   R_000E60_SRBM_SOFT_RESET=0x00000402
Comment 2 Alex Deucher 2009-12-11 07:29:08 UTC
Can you bisect the problematic commit?
Comment 3 Rafał Miłecki 2009-12-11 09:49:00 UTC
Created attachment 31990 [details]
git bisect log

ec42a6e7dcfc2e9a92fad1c132bc9e110fafeb3f is the first bad commit
commit ec42a6e7dcfc2e9a92fad1c132bc9e110fafeb3f
Author: Dave Airlie <airlied@redhat.com>
Date:   Tue Dec 8 15:58:08 2009 +1000

    drm/ttm: fix memory leak noticed by kmemleak.

    If we don't need the zone we need to free it.

    Acked-By: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 c65430b9f69957be4d0bc67be14c8deacfac58a9 f84a05852ae0b05680ca69bae650a389ce36e598 M      drivers
Comment 4 Thomas Hellström 2009-12-11 10:44:45 UTC
What you're seeing is a probable GPU lockup.

It can't possibly have anything to do with the commit stated.
Comment 5 Rafał Miłecki 2009-12-12 01:04:21 UTC
(In reply to comment #4)
> What you're seeing is a probable GPU lockup.
> It can't possibly have anything to do with the commit stated.

I suspected some timing issue or compiler error... Couldn't get you or Dave on IRC. But indeed you're right, reverting this commit does not help.
Comment 6 Rafał Miłecki 2009-12-12 01:08:25 UTC
Created attachment 32016 [details]
results of manual bisecting
Comment 7 Rafał Miłecki 2009-12-12 01:21:54 UTC
commit 66e145488241836775591cd5efc5692ceabd06cf
Author: root <root@linux-g0th.site>
Date:   Sat Dec 12 09:58:51 2009 +0100

    Revert "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure"

    This reverts commit 779720a3209849be202ac36a811e934865c50971.

3 warm boots, 3 cold boots, all succeed.
Comment 8 Rafał Miłecki 2009-12-12 03:23:13 UTC
Created attachment 32017 [details]
patch that *does not* fix problem
Comment 9 Rafał Miłecki 2009-12-12 03:23:24 UTC
Created attachment 32018 [details]
patch that *does not* fix problem
Comment 10 Rafał Miłecki 2009-12-12 03:23:50 UTC
Created attachment 32019 [details] [review]
patch that *does* fix problem
Comment 11 Florian Scandella 2009-12-12 11:44:12 UTC
i also have problems with this commit (although different, see bug #25567) ... will try your patch soon
Comment 12 Tom Stellard 2009-12-12 15:00:19 UTC
I have a similar error, but I have an R300 card (Radeon xpress 200m).  When I have KMS enabled, X locks up when I start firefox, or glxgears (basically anything besides xterm).  This error message is repeated in /var/log/dmesg:

[drm:radeon_fence_wait] *ERROR* fence(e9d50600:0x00000356) 521ms timeout
[drm:radeon_fence_wait] *ERROR* last signaled fence(0x00000356)
[drm:radeon_fence_wait] *ERROR* fence(e9d50620:0x00000357) 510ms timeout going to reset GPU
[drm] CP reset succeed (RBBM_STATUS=0x00000140)
[drm] radeon: cp idle (0x10000000)
[drm] radeon: ring at 0x0000000030000000
[drm] ring test succeeded in 0 usecs
[drm] GPU reset succeed (RBBM_STATUS=0x00000140)

I am using the the latest git versions of
libdrm: edc77dd291594e017ca0ee96a785412107ebff74
mesa: 784cca9fa527de771754d76545970f78094b9adf
xorg radeon driver: 0e5c9d87b5d7e0751df71cc8958ca5ccaed25104
kernel: 6eb7365db6f3a4a9d8d9922bb0b800f9cbaad641

X-server: 1.7.3
Comment 13 Alex Deucher 2009-12-15 14:22:39 UTC

*** This bug has been marked as a duplicate of bug 25567 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.