Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756616Ab3DRTsJ (ORCPT ); Thu, 18 Apr 2013 15:48:09 -0400 Received: from mail-ie0-f170.google.com ([209.85.223.170]:53907 "EHLO mail-ie0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752975Ab3DRTsH (ORCPT ); Thu, 18 Apr 2013 15:48:07 -0400 MIME-Version: 1.0 X-Originating-IP: [178.83.130.250] In-Reply-To: References: Date: Thu, 18 Apr 2013 21:48:06 +0200 Message-ID: Subject: Re: linux-next: Tree for Apr 18 [ call-trace: drm | x86 | smp | rcu related? ] From: Daniel Vetter To: Sedat Dilek Cc: Stephen Rothwell , linux-next , Linux Kernel Mailing List , x86@kernel.org, Ingo Molnar , Thomas Gleixner , Paul McKenney , Paul McKenney , DRI , Dave Airlie Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1717 Lines: 47 On Thu, Apr 18, 2013 at 3:05 PM, Sedat Dilek wrote: > On Thu, Apr 18, 2013 at 10:28 AM, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20130417: >> >> New Trees: rpmsg (actually added yesterday) >> ppc-temp (replacing powerpc for this week) >> >> The ceph tree gained a conflict against Linus' tree. >> >> The net-next tree gained a conflict against the infiniband tree. >> >> The usb tree gained a build failure so I used the version from >> next-20130417. >> >> I added two merge fix patches after the gen-gpio tree. >> >> The ppc-temp tree gained a conflict against the metag tree. >> >> The akpm tree lost a patch that turned up elsewhere. >> >> ---------------------------------------------------------------------------- >> > > Not sure what the root-cause for this call-trace is (see screenshot). > > This is reproducible when running my kernel build-script (4 parallel-make-jobs). > > Any hints welcome! The panic handlers in our modeset code are pretty decent fubar - they take mutexes all over the place. So I think the backtrace you see there is actually a secondary effect. I've looked into fixing this up, but the issue is that drivers themselves have tons of state protected with mutexes, which all potentially affects the panic handler. So I've given up on that for now ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/