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