From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754674AbbCBQyD (ORCPT ); Mon, 2 Mar 2015 11:54:03 -0500 Received: from mail-ie0-f179.google.com ([209.85.223.179]:35508 "EHLO mail-ie0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753091AbbCBQyB (ORCPT ); Mon, 2 Mar 2015 11:54:01 -0500 MIME-Version: 1.0 In-Reply-To: <20150302090409.GV24485@phenom.ffwll.local> References: <20150302090409.GV24485@phenom.ffwll.local> Date: Mon, 2 Mar 2015 08:53:59 -0800 X-Google-Sender-Auth: c5mZPGDsQCjea5epbuM5EPhallA Message-ID: Subject: Re: [git pull] drm fixes From: Linus Torvalds To: Linus Torvalds , Dave Airlie , Daniel Vetter , Jani Nikula , Matt Roper , Ander Conselvan de Oliveira , intel-gfx , Linux Kernel Mailing List , DRI mailing list Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 2, 2015 at 1:04 AM, Daniel Vetter wrote: > > And can you please attach a bactrace of the WARN in your patch, just to > double-check you blow up at the same spot? So the dmesg I attached had a backtrace for the new WARN_ONCE() (in addition to an unrelated(?) one from i915_gem_free_object()). Or did you mean a backtrace of the oops when things go wrong, when my patch is *not* applied? My first email had that with the kref.h warning from drm_framebuffer_reference, which is otherwise the same thing. And after things go wrong, and the plane handling thing uses a framebuffer that has already been freed, then the resulting oopses end up being kind of random. Which was partly why it ended up beign so hard to finally bisect, and I actually eventually gave up on it - because sometimes things would just happen to work, sometimes things would blow up and oops when X started (resulting in just a dead machine), sometimes things would oops at bootup. The most common oops was something going wrong when the framebuffer was free'd for the second time, and it would cause a NULL pointer dereference in drm_framebuffer_free() or one of the routines it called (so often a NULL pointer dereference in "mutex_lock(&dev->mode_config.fb_lock)" because "dev" was NULL, or the call to "fb->funcs->destroy(fb)" would oops because "fb->funcs" was NULL. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [git pull] drm fixes Date: Mon, 2 Mar 2015 08:53:59 -0800 Message-ID: References: <20150302090409.GV24485@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20150302090409.GV24485@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Linus Torvalds , Dave Airlie , Daniel Vetter , Jani Nikula , Matt Roper , Ander Conselvan de Oliveira , intel-gfx , Linux Kernel Mailing List , DRI mailing list List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBNYXIgMiwgMjAxNSBhdCAxOjA0IEFNLCBEYW5pZWwgVmV0dGVyIDxkYW5pZWxAZmZ3 bGwuY2g+IHdyb3RlOgo+Cj4gQW5kIGNhbiB5b3UgcGxlYXNlIGF0dGFjaCBhIGJhY3RyYWNlIG9m IHRoZSBXQVJOIGluIHlvdXIgcGF0Y2gsIGp1c3QgdG8KPiBkb3VibGUtY2hlY2sgeW91IGJsb3cg dXAgYXQgdGhlIHNhbWUgc3BvdD8KClNvIHRoZSBkbWVzZyBJIGF0dGFjaGVkIGhhZCBhIGJhY2t0 cmFjZSBmb3IgdGhlIG5ldyBXQVJOX09OQ0UoKSAoaW4KYWRkaXRpb24gdG8gYW4gdW5yZWxhdGVk KD8pIG9uZSBmcm9tIGk5MTVfZ2VtX2ZyZWVfb2JqZWN0KCkpLgoKT3IgZGlkIHlvdSBtZWFuIGEg YmFja3RyYWNlIG9mIHRoZSBvb3BzIHdoZW4gdGhpbmdzIGdvIHdyb25nLCB3aGVuIG15CnBhdGNo IGlzICpub3QqIGFwcGxpZWQ/IE15IGZpcnN0IGVtYWlsIGhhZCB0aGF0IHdpdGggdGhlIGtyZWYu aAp3YXJuaW5nIGZyb20gZHJtX2ZyYW1lYnVmZmVyX3JlZmVyZW5jZSwgd2hpY2ggaXMgb3RoZXJ3 aXNlIHRoZSBzYW1lCnRoaW5nLgoKQW5kIGFmdGVyIHRoaW5ncyBnbyB3cm9uZywgYW5kIHRoZSBw bGFuZSBoYW5kbGluZyB0aGluZyB1c2VzIGEKZnJhbWVidWZmZXIgdGhhdCBoYXMgYWxyZWFkeSBi ZWVuIGZyZWVkLCB0aGVuIHRoZSByZXN1bHRpbmcgb29wc2VzIGVuZAp1cCBiZWluZyBraW5kIG9m IHJhbmRvbS4gV2hpY2ggd2FzIHBhcnRseSB3aHkgaXQgZW5kZWQgdXAgYmVpZ24gc28KaGFyZCB0 byBmaW5hbGx5IGJpc2VjdCwgYW5kIEkgYWN0dWFsbHkgZXZlbnR1YWxseSBnYXZlIHVwIG9uIGl0 IC0KYmVjYXVzZSBzb21ldGltZXMgdGhpbmdzIHdvdWxkIGp1c3QgaGFwcGVuIHRvIHdvcmssIHNv bWV0aW1lcyB0aGluZ3MKd291bGQgYmxvdyB1cCBhbmQgb29wcyB3aGVuIFggc3RhcnRlZCAocmVz dWx0aW5nIGluIGp1c3QgYSBkZWFkCm1hY2hpbmUpLCBzb21ldGltZXMgdGhpbmdzIHdvdWxkIG9v cHMgYXQgYm9vdHVwLgoKVGhlIG1vc3QgY29tbW9uIG9vcHMgd2FzIHNvbWV0aGluZyBnb2luZyB3 cm9uZyB3aGVuIHRoZSBmcmFtZWJ1ZmZlcgp3YXMgZnJlZSdkIGZvciB0aGUgc2Vjb25kIHRpbWUs IGFuZCBpdCB3b3VsZCBjYXVzZSBhIE5VTEwgcG9pbnRlcgpkZXJlZmVyZW5jZSBpbiBkcm1fZnJh bWVidWZmZXJfZnJlZSgpIG9yIG9uZSBvZiB0aGUgcm91dGluZXMgaXQgY2FsbGVkCihzbyBvZnRl biBhIE5VTEwgcG9pbnRlciBkZXJlZmVyZW5jZSBpbgoibXV0ZXhfbG9jaygmZGV2LT5tb2RlX2Nv bmZpZy5mYl9sb2NrKSIgYmVjYXVzZSAiZGV2IiB3YXMgTlVMTCwgb3IgdGhlCmNhbGwgdG8gImZi LT5mdW5jcy0+ZGVzdHJveShmYikiIHdvdWxkIG9vcHMgYmVjYXVzZSAiZmItPmZ1bmNzIiB3YXMK TlVMTC4KCiAgICAgICAgICAgICAgICAgICAgICAgICBMaW51cwpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVs LWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ludGVsLWdmeAo=