All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Ortwin Glück" <odi@odi.ch>, linux-kernel@vger.kernel.org
Subject: Re: [bisected] drm/radeon: fences regression
Date: Sat, 22 Mar 2014 18:01:52 +0100	[thread overview]
Message-ID: <532DC200.7070409@amd.com> (raw)
In-Reply-To: <532DA935.4010907@odi.ch>

Hi Ortwin,

unfortunately the iMacs are notorious problematic and it's likely that 
something didn't worked before and you never noticed it because the 
kernel didn't complained. Have you ever tried to use UVD on that system?

On the other hand the failed UVD init shouldn't affect the rest of the 
system (3D should work fine), so there is really something odd here.

Please open up a bug report on 
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI component 
DRM/Radeon and attach at least the full dmesg output of 3.13 as well as 
3.12.

Thanks in advance,
Christian.

Am 22.03.2014 16:16, schrieb Ortwin Glück:
> Hi,
>
> I am seeing a GPU lockup from any v3.13 up to 3.14-rc7, which 
> basically renders my computer unusable under recent kernels :-(
>
> [   55.762710] radeon 0000:01:00.0: GPU lockup CP stall for more than 
> 10000msec
> [   55.762715] radeon 0000:01:00.0: GPU lockup (waiting for 
> 0x0000000000000004 last fence id 0x000000000000000 on ring 5)
> [   55.762717] [drm:uvd_v1_0_ib_test] *ERROR* radeon: fence wait 
> failed (-35).
> [   55.762720] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed 
> testing IB on ring 5 (-35).
>
> Hardware is an iMac 11,2 with a Radeon 4670 M96XT (RV730), 256MB GDDR3.
>
>
> Bisected to this commit:
>
> commit f9eaf9ae782d6480f179850e27e6f4911ac10227
> Author: Christian König <christian.koenig@amd.com>
> Date:   Tue Oct 29 20:14:47 2013 +0100
>
>     drm/radeon: rework and fix reset detection v2
>
>     Stop fiddling with jiffies, always wait for 
> RADEON_FENCE_JIFFIES_TIMEOUT.
>     Consolidate the two wait sequence implementations into just one 
> function.
>     Activate all waiters and remember if the reset was already done 
> instead of
>     trying to reset from only one thread.
>
>     v2: clear reset flag earlier to avoid timeout in IB test
>
> Unfortunately this patch no longer cleanly unapplies on v3.13.



  reply	other threads:[~2014-03-22 17:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22 15:16 [bisected] drm/radeon: fences regression Ortwin Glück
2014-03-22 17:01 ` Christian König [this message]
2014-03-23 10:05   ` Ortwin Glück

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=532DC200.7070409@amd.com \
    --to=christian.koenig@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=odi@odi.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.