From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757450AbaGWI0O (ORCPT ); Wed, 23 Jul 2014 04:26:14 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:47482 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757367AbaGWI0C (ORCPT ); Wed, 23 Jul 2014 04:26:02 -0400 Message-ID: <53CF7191.2090008@canonical.com> Date: Wed, 23 Jul 2014 10:25:53 +0200 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Daniel Vetter , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= CC: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> <53CE84AA.9030703@amd.com> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> <53CF699D.9070902@canonical.com> <53CF6B18.5070107@vodafone.de> <53CF7035.2060808@amd.com> In-Reply-To: <53CF7035.2060808@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org op 23-07-14 10:20, Christian König schreef: > Am 23.07.2014 10:07, schrieb Daniel Vetter: >> On Wed, Jul 23, 2014 at 9:58 AM, Christian König >> wrote: >>> Just imagine an application using prime is locking up Radeon and because of >>> that gets killed by the user. Nothing else in the system would use the >>> Radeon hardware any more and so radeon gets only called by another driver >>> waiting patiently for radeon to finish rendering which never happens because >>> the whole thing is locked up and we don't get a chance to recover. >> But isn't that possible already without fences? X hangs radeon, user >> crashes X for unrelated reasons before radeon will notice the hang. >> Then no one uses radeon any longer and the hang stays undetected. > > Yeah, especially with multimedia application. But I don't really care about this problem because the next time an application tries to use the block in question we actually do the reset and everything is fine. > > In your example we would do the reset when the next X server starts, before that point nobody would care because nobody uses the hardware. > > An additional problem here is that resets are something perfect normal for radeon. For example UVD can "crash" when you feed it with invalid bitstream data, (ok actually it send an interrupt and stops any processing for the driver to investigate). To continue processing you need to go through a rather complicated reset procedure. In this case if the sync was to i915 the i915 lockup procedure would take care of itself. It wouldn't fix radeon, but it would at least unblock your intel card again. I haven't specifically added a special case to attempt to unblock external fences, but I've considered it. :-) ~Maarten From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: [PATCH 09/17] drm/radeon: use common fence implementation for fences Date: Wed, 23 Jul 2014 10:25:53 +0200 Message-ID: <53CF7191.2090008@canonical.com> References: <20140709093124.11354.3774.stgit@patser> <20140709122953.11354.46381.stgit@patser> <53CE2421.5040906@amd.com> <20140722114607.GL15237@phenom.ffwll.local> <20140722115737.GN15237@phenom.ffwll.local> <53CE56ED.4040109@vodafone.de> <20140722132652.GO15237@phenom.ffwll.local> <53CE6AFA.1060807@vodafone.de> <53CE84AA.9030703@amd.com> <53CE8A57.2000803@vodafone.de> <53CF58FB.8070609@canonical.com> <53CF5B9F.1050800@amd.com> <53CF5EFE.6070307@canonical.com> <53CF63C2.7070407@vodafone.de> <53CF6622.6060803@amd.com> <53CF699D.9070902@canonical.com> <53CF6B18.5070107@vodafone.de> <53CF7035.2060808@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <53CF7035.2060808-5C7GfCeVMHo@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Nouveau" To: =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= , Daniel Vetter , =?UTF-8?B?Q2hyaXN0aWFuIEvDtm5pZw==?= Cc: Thomas Hellstrom , nouveau , LKML , dri-devel , Ben Skeggs , "Deucher, Alexander" List-Id: nouveau.vger.kernel.org b3AgMjMtMDctMTQgMTA6MjAsIENocmlzdGlhbiBLw7ZuaWcgc2NocmVlZjoKPiBBbSAyMy4wNy4y MDE0IDEwOjA3LCBzY2hyaWViIERhbmllbCBWZXR0ZXI6Cj4+IE9uIFdlZCwgSnVsIDIzLCAyMDE0 IGF0IDk6NTggQU0sIENocmlzdGlhbiBLw7ZuaWcKPj4gPGRlYXRoc2ltcGxlQHZvZGFmb25lLmRl PiB3cm90ZToKPj4+IEp1c3QgaW1hZ2luZSBhbiBhcHBsaWNhdGlvbiB1c2luZyBwcmltZSBpcyBs b2NraW5nIHVwIFJhZGVvbiBhbmQgYmVjYXVzZSBvZgo+Pj4gdGhhdCBnZXRzIGtpbGxlZCBieSB0 aGUgdXNlci4gTm90aGluZyBlbHNlIGluIHRoZSBzeXN0ZW0gd291bGQgdXNlIHRoZQo+Pj4gUmFk ZW9uIGhhcmR3YXJlIGFueSBtb3JlIGFuZCBzbyByYWRlb24gZ2V0cyBvbmx5IGNhbGxlZCBieSBh bm90aGVyIGRyaXZlcgo+Pj4gd2FpdGluZyBwYXRpZW50bHkgZm9yIHJhZGVvbiB0byBmaW5pc2gg cmVuZGVyaW5nIHdoaWNoIG5ldmVyIGhhcHBlbnMgYmVjYXVzZQo+Pj4gdGhlIHdob2xlIHRoaW5n IGlzIGxvY2tlZCB1cCBhbmQgd2UgZG9uJ3QgZ2V0IGEgY2hhbmNlIHRvIHJlY292ZXIuCj4+IEJ1 dCBpc24ndCB0aGF0IHBvc3NpYmxlIGFscmVhZHkgd2l0aG91dCBmZW5jZXM/IFggaGFuZ3MgcmFk ZW9uLCB1c2VyCj4+IGNyYXNoZXMgWCBmb3IgdW5yZWxhdGVkIHJlYXNvbnMgYmVmb3JlIHJhZGVv biB3aWxsIG5vdGljZSB0aGUgaGFuZy4KPj4gVGhlbiBubyBvbmUgdXNlcyByYWRlb24gYW55IGxv bmdlciBhbmQgdGhlIGhhbmcgc3RheXMgdW5kZXRlY3RlZC4KPgo+IFllYWgsIGVzcGVjaWFsbHkg d2l0aCBtdWx0aW1lZGlhIGFwcGxpY2F0aW9uLiBCdXQgSSBkb24ndCByZWFsbHkgY2FyZSBhYm91 dCB0aGlzIHByb2JsZW0gYmVjYXVzZSB0aGUgbmV4dCB0aW1lIGFuIGFwcGxpY2F0aW9uIHRyaWVz IHRvIHVzZSB0aGUgYmxvY2sgaW4gcXVlc3Rpb24gd2UgYWN0dWFsbHkgZG8gdGhlIHJlc2V0IGFu ZCBldmVyeXRoaW5nIGlzIGZpbmUuCj4KPiBJbiB5b3VyIGV4YW1wbGUgd2Ugd291bGQgZG8gdGhl IHJlc2V0IHdoZW4gdGhlIG5leHQgWCBzZXJ2ZXIgc3RhcnRzLCBiZWZvcmUgdGhhdCBwb2ludCBu b2JvZHkgd291bGQgY2FyZSBiZWNhdXNlIG5vYm9keSB1c2VzIHRoZSBoYXJkd2FyZS4KPgo+IEFu IGFkZGl0aW9uYWwgcHJvYmxlbSBoZXJlIGlzIHRoYXQgcmVzZXRzIGFyZSBzb21ldGhpbmcgcGVy ZmVjdCBub3JtYWwgZm9yIHJhZGVvbi4gRm9yIGV4YW1wbGUgVVZEIGNhbiAiY3Jhc2giIHdoZW4g eW91IGZlZWQgaXQgd2l0aCBpbnZhbGlkIGJpdHN0cmVhbSBkYXRhLCAob2sgYWN0dWFsbHkgaXQg c2VuZCBhbiBpbnRlcnJ1cHQgYW5kIHN0b3BzIGFueSBwcm9jZXNzaW5nIGZvciB0aGUgZHJpdmVy IHRvIGludmVzdGlnYXRlKS4gVG8gY29udGludWUgcHJvY2Vzc2luZyB5b3UgbmVlZCB0byBnbyB0 aHJvdWdoIGEgcmF0aGVyIGNvbXBsaWNhdGVkIHJlc2V0IHByb2NlZHVyZS4KSW4gdGhpcyBjYXNl IGlmIHRoZSBzeW5jIHdhcyB0byBpOTE1IHRoZSBpOTE1IGxvY2t1cCBwcm9jZWR1cmUgd291bGQg dGFrZSBjYXJlIG9mIGl0c2VsZi4gSXQgd291bGRuJ3QgZml4IHJhZGVvbiwgYnV0IGl0IHdvdWxk IGF0IGxlYXN0IHVuYmxvY2sgeW91ciBpbnRlbCBjYXJkIGFnYWluLiBJIGhhdmVuJ3Qgc3BlY2lm aWNhbGx5IGFkZGVkIGEgc3BlY2lhbCBjYXNlIHRvIGF0dGVtcHQgdG8gdW5ibG9jayBleHRlcm5h bCBmZW5jZXMsIGJ1dCBJJ3ZlIGNvbnNpZGVyZWQgaXQuIDotKQoKfk1hYXJ0ZW4KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5vdXZlYXUgbWFpbGluZyBs aXN0Ck5vdXZlYXVAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3Rv cC5vcmcvbWFpbG1hbi9saXN0aW5mby9ub3V2ZWF1Cg==