From patchwork Thu Oct 8 17:47:44 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tim Gardner X-Patchwork-Id: 35501 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id E6A85B7B71 for ; Fri, 9 Oct 2009 04:48:03 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1Mvx5n-000362-11; Thu, 08 Oct 2009 18:47:55 +0100 Received: from mail.tpi.com ([70.99.223.143]) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1Mvx5e-00032x-96 for kernel-team@lists.ubuntu.com; Thu, 08 Oct 2009 18:47:46 +0100 Received: from [10.0.2.5] (unknown [10.0.2.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.tpi.com (Postfix) with ESMTP id 10FA61F00AF; Thu, 8 Oct 2009 10:47:19 -0700 (PDT) Message-ID: <4ACE25C0.6040505@canonical.com> Date: Thu, 08 Oct 2009 11:47:44 -0600 From: Tim Gardner User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andy Whitcroft Subject: Re: console messages and log level References: <20091008164440.GF4945@shadowen.org> In-Reply-To: <20091008164440.GF4945@shadowen.org> X-Enigmail-Version: 0.95.7 Cc: Ubuntu Kernel Team X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.8 Precedence: list Reply-To: tim.gardner@canonical.com List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com Andy Whitcroft wrote: > We are now moving into new territory where the kernel is naked in front > of the user for some seconds before xsplash covers its blushes. The > kernel has traditionally been very chatty and although it has a 'quiet' > mode which we use for normal boots it is still keen to tell us about a > lot of events and errors. > > During the lifetime of the kernel it is only this very early phase where > any messages are visible at all. Once X has started the console is gone, > even 'emergency' messages are only visible via dmesg. Until recently > usplash was also hiding our messages, again hiding every message level. > Generally in the life the kernel, its idea of importance is ignored, and as > a result not all of its levels are accurate; leading to the issue at hand. > > Now we can attempt to fix these messages so they come out at lower levels > (KERN_WARN or lower), indeed we are already seeing requests to quieten > some of these messages. Typically we do this by dropping the severity of > those messages via a patch, a patch which typically upstream is unlikely > to want and which we will have to carry for the long haul. > > Does it really make sense for us to carry a large number of silencer > patches? I am not convinced. As we are happy for X to hide all messages > and indeed we added usplash to hide them before X started, perhaps the > sensible thing to do is simply suppress them completely on a regular boot. > The kernel already has a log_level indicating which messages are important > enough to display on the real console and we use this to control verbosity > on boot. > > When we look at a normal boot we boot with 'quiet' on the command line. > This lowers the kernels noise level and is also passed to userspace which > again reacts quieting it init.d script logging levels and the like. If > things fail we normally boot without 'quiet' and we get the full glory > of the kernel output and userspace output too. > > To cut to the chase, rather than patching lots of kernel messages to lower > their level might it make just as much sense to lower the level at which > console messages are emitted in the face of the 'queiet' command. To allow > the kernel to shield itself more heavily. We could probabally lower the > console level from the default 4 to 1 allowing only emergency messages > to be seen without losing anything in the debug case. Messages are still > logged to the dmesg and thus the logs, and if booting is broken removing > 'quiet' will give us all messages, and indeed log_level=4 will give us > the current behaviour. > > In short. We try very hard in normal running to hide the kernel and are > happy to hide it completly, why is early boot any different. > > If you think this makes sens I can spin a patch for testing. > > -apw > thusly? Acked-by: Andy Whitcroft From 1aba8a4352402396a42140b2b177abce44d920b7 Mon Sep 17 00:00:00 2001 From: Tim Gardner Date: Thu, 8 Oct 2009 11:42:36 -0600 Subject: [PATCH] UBUNTU: SAUCE: Raise the default console 'quiet' level to 2 In the interests of providing a clean boot experience, i.e., a blank screen before X starts, supress noisy driver messages. See https://lists.ubuntu.com/archives/kernel-team/2009-October/007476.html for the original diatribe. Signed-off-by: Tim Gardner --- init/main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/init/main.c b/init/main.c index 11f4f14..a97d0b7 100644 --- a/init/main.c +++ b/init/main.c @@ -233,7 +233,7 @@ static int __init debug_kernel(char *str) static int __init quiet_kernel(char *str) { - console_loglevel = 4; + console_loglevel = 2; return 0; } -- 1.6.2.4