Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752790AbbF3GhF (ORCPT ); Tue, 30 Jun 2015 02:37:05 -0400 Received: from mail-ob0-f171.google.com ([209.85.214.171]:35067 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752108AbbF3Gg7 (ORCPT ); Tue, 30 Jun 2015 02:36:59 -0400 MIME-Version: 1.0 X-Originating-IP: [212.51.149.109] In-Reply-To: <1435632837-32056-1-git-send-email-rui.y.wang@intel.com> References: <1435632837-32056-1-git-send-email-rui.y.wang@intel.com> Date: Tue, 30 Jun 2015 08:36:58 +0200 Message-ID: Subject: Re: drm/mgag200: doesn't work in panic context From: Daniel Vetter To: Rui Wang Cc: Borislav Petkov , "Luck, Tony" , Dave Airlie , "Clark, Rob" , Matthew D Roper , "Chen, Gong" , Linux Kernel 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 Content-Length: 1688 Lines: 35 On Tue, Jun 30, 2015 at 4:53 AM, Rui Wang wrote: > On Monday, June 29, 2015 5:25 PM, Daniel Vetter wrote: >> As long as the display is up and running we should have a fair stab at >> showing the oops - it's just that no one has seriously bothered with >> the necessary infastructure, automated testing (it won't work >> otherwise) and driver work. > > I think testing can be done by injecting a fatal machine check exception > via einj's debugfs interface. I can reproduce the hard hang every time. > I think It can be a simple script or C program do to the automated testing. > If anyone has any patch I'll be happy to help test it out. Testing shouldn't kill the machine ;-) The idea I had is to just exercise the drm panic code (since we'd need to shunt everything else), and that can be done my calling the relevant functions from a hardirq context. And hardirq context is simples to get with a IPI to the local cpu. This way we don't depend upon the entire panic path to be recoverable, but only upon the drm bits being sane. The other thing that needs testing is pushing all the fbdev callbacks into workers if run from non-process context. But that's something fbdev likes doing anyway (it's just that most drivers don't need to overwrite the hooks where this usually happens). -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/