Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757312AbZFWB72 (ORCPT ); Mon, 22 Jun 2009 21:59:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751676AbZFWB7V (ORCPT ); Mon, 22 Jun 2009 21:59:21 -0400 Received: from gate.crashing.org ([63.228.1.57]:60901 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751037AbZFWB7U (ORCPT ); Mon, 22 Jun 2009 21:59:20 -0400 Subject: Re: [git pull] drm: previous pull req + 1. From: Benjamin Herrenschmidt To: Jesse Barnes Cc: Linus Torvalds , Thomas =?ISO-8859-1?Q?Hellstr=F6m?= , Dave Airlie , Alex Deucher , Andrew Lutomirski , dri-devel@lists.sf.net, Jerome Glisse , Linux Kernel Mailing List In-Reply-To: <20090622181832.771dac03@jbarnes-g45> References: <4A3DABE1.50309@mit.edu> <4A3F3E3A.2030202@shipmail.org> <1245715213.4017.13.camel@pasglop> <1245719079.4017.25.camel@pasglop> <20090622181832.771dac03@jbarnes-g45> Content-Type: text/plain Date: Tue, 23 Jun 2009 11:58:44 +1000 Message-Id: <1245722325.4017.29.camel@pasglop> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1538 Lines: 37 On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote: > I think it could work, but ideally we'd keep the kernel fbcon object > pinned, and keep printing into it even while some other gfx app is > running. That way we don't have to dump the whole queue into it when > a > panic occurs, we can just switch buffers (something like this would > also be handy for dual head debugging; one head running your desktop > and the other a debug console printing all the messages). That's > slightly more invasive surgery though... I should have a chance to do > something like that as part of the kdb/kms work I'll be doing with > Jason. > Do we really need that ? We can easily repaint (ie, regenerate the fb content from the pseudo vgacon image kept by the console layer). So if we want the kernel to "take" over, it's reasonably easy to make it also repaint the content of the fb. How, of course, kicking out usespace with unmap_mapping_ranges() isn't going to work well from an oops or something at interrupt time, we do need to have a reasonably safe path for these things, which is why I believe that sort of emergency printing should be done without any acceleration, just basic manual painting in the front buffer... Should we even bother changing the mode ? Not sure... Cheers, Ben. -- 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/