From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA9B1220F21 for ; Sun, 23 Nov 2025 21:21:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763932875; cv=none; b=NahMcK9zl5rwE1PRRuQa4MHjvVsbNkhtS5J4Hf6LzMaCB8u5UTdGYwC2i8bvLUYBmZCr5E7sI7MY7hCQmbYIOqR7nx9DaZRwCiEfJq1j7ueKKF6OqfX4Z1ZA96EOD5V6EzyaK5HPwMLAMo5DPm1G+6aoZJFoDf+ldm0zlB/8XF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763932875; c=relaxed/simple; bh=8pzZ5iXtiCsBhq2SXowOyyY1G9feS7I3QXeO+9Y8PU8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=NvJGjxFmLEBJg9K4C5InFfJtgyESonQKbDrcVAJCCNOY0AuZGtRoqpS/ByQCVHq/Sot5SFm0sjCIjNq8ZYP0MCu1MTZHVVVRjmkYG8/aJaaJYLiyid/l1He9bcPvLZet5cr5Twz46zpgKpha48lE9y2XESmsCBULzJj6aYPSCbY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=v40KhejB; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=7AyO95+2; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="v40KhejB"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="7AyO95+2" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763932865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4wTQXQ9MuXpkdKnR1SoR0E60GASCQ56/gLNm7BCJu2U=; b=v40KhejBRK7kZyCMqhImEQt/tCzLo7wCbl4+YPGCkn458Q2Llk0ycL+RwyJ+fYiuptFRyf w6SF1H6WNgu94A/m0mZOkK4F4LwZdAroKDDs7EHItFdxnpxJL8E/ETOEMmIHcIdBMEZ2Fh J5QPjBlmT2Z651cnO/9VTTg1KIKXYVGnNIHE1baevoypTrIjKJMWgwvKeCSHgtjERXk1ME JGLFVc+1b4MWGiIkveR658zWA+N+5rwSLPQh3ZUJCeB144u2m0FB/qwyJE7xvnIEpWY65m mTy7+GgxW0KDHT4HoE95RsjMCVfaG9UNJ3h+y9djDg7Wx4TvJjuRUWd8lNXoyQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763932865; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4wTQXQ9MuXpkdKnR1SoR0E60GASCQ56/gLNm7BCJu2U=; b=7AyO95+2Sb48S8nmxbpp+4IzqJVtfkV397OyJNRkGUdaSF9SRBgLu4oP0FNcHEYGHDZHyD VU7YMjLa3S0FAPAg== To: Chris Down , Petr Mladek Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sergey Senozhatsky , Steven Rostedt , Geert Uytterhoeven , Tony Lindgren , kernel-team@fb.com Subject: Re: [PATCH v7 11/13] printk: docs: Add comprehensive guidance for per-console loglevels In-Reply-To: <60de5c9e249579d8d4e5a9423067157a462eb763.1763492585.git.chris@chrisdown.name> References: <60de5c9e249579d8d4e5a9423067157a462eb763.1763492585.git.chris@chrisdown.name> Date: Sun, 23 Nov 2025 22:27:04 +0106 Message-ID: <87qztofnsv.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 2025-11-19, Chris Down wrote: > diff --git a/Documentation/admin-guide/per-console-loglevel.rst b/Documentation/admin-guide/per-console-loglevel.rst > index 4908d5d8ed4f..69eede12e20f 100644 > --- a/Documentation/admin-guide/per-console-loglevel.rst > +++ b/Documentation/admin-guide/per-console-loglevel.rst > @@ -97,6 +97,158 @@ are using ``ttyS0``, the console backing it can be viewed at > This will be in effect if no other global control overrides it. Look at > ``effective_loglevel`` and ``effective_loglevel_source`` to verify that. > > +Examples > +-------- > + > +Setting per-console loglevel at runtime > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +Set serial console to only show warnings and above (level 4):: > + > + echo 4 > /sys/class/console/ttyS0/loglevel Setting it to 4 would only show "above warnings" ... you will not see warning messages. > + > +Set netconsole to show info and above (level 6):: > + > + echo 6 > /sys/class/console/netcon0/loglevel Setting it to 6 would only show "above info" ... you will not see info messages. > +Common use case - high performance with serial fallback > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +A common configuration is to set netconsole to a verbose level for normal > +debugging, while keeping the serial console quiet to avoid performance impact, > +but still available for emergencies:: > + > + # Netconsole gets INFO and above (verbose) > + echo 6 > /sys/class/console/netcon0/loglevel 6 only shows "above INFO" ... you will not see INFO. > + > + # Serial console gets only WARN and above (quiet, for emergencies) > + echo 4 > /sys/class/console/ttyS0/loglevel 4 only shows "above WARN" ... you will not see WARN. > + > +This allows you to see informational messages on the fast netconsole without > +the latency impact of writing them to the slow serial port. > + > +Performance Impact > +------------------ > + > +When a console has a higher (less verbose) loglevel than the global level, > +messages that would normally be sent to that console are filtered out before > +the console write callback is invoked. This eliminates the latency that would > +be incurred by writing those messages to slow consoles (e.g., serial ports). > + > +For example, setting a serial console to WARN level (4) while keeping > +netconsole at INFO level (6) prevents INFO and NOTICE messages from being > +written to the slow serial port, reducing application stalls during verbose > +logging periods. Setting serial to 4 will also prevent WARN messages. > + > +Serial console writes can take tens of milliseconds per message. During > +periods of heavy logging (e.g., during network debugging or block I/O tracing), > +this can cause significant application-level stalls. By setting a higher > +per-console loglevel for the serial console, you can avoid these stalls while > +still capturing all messages on faster consoles like netconsole. > + > +Troubleshooting > +--------------- > + > +Messages not appearing on console despite setting loglevel > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +1. Check effective loglevel source:: > + > + cat /sys/class/console//effective_loglevel_source > + > + If it shows ``ignore_loglevel``, you have the ``printk.ignore_loglevel`` > + kernel parameter set, which overrides all level controls. Remove it from > + your kernel command line or set it to N in sysfs:: > + > + echo N > /sys/module/printk/parameters/ignore_loglevel > + > +2. Check if per-console loglevels are being ignored:: > + > + cat /sys/module/printk/parameters/ignore_per_console_loglevel > + > + If it shows ``Y``, per-console settings are disabled. Set it to N:: > + > + echo N > /sys/module/printk/parameters/ignore_per_console_loglevel > + > +3. Verify the message priority is high enough:: > + > + cat /sys/class/console//effective_loglevel > + > + Messages must have priority less than this value to appear. For example, > + if effective_loglevel is 4, only messages with priority 0-3 (EMERG, ALERT, > + CRIT, ERR) will be printed. If you want to see WARN messages (priority 4), > + you need to increase the effective_loglevel to at least 5. Yay! Here it is documented correctly. ;-) > + > +Cannot set loglevel to 0 > +~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +Per-console loglevels cannot be set to 0 (KERN_EMERG). This is by design, as > +level 0 is reserved for the most critical system messages that should always > +go to all consoles. To use the global loglevel, set the per-console loglevel > +to -1:: > + > + echo -1 > /sys/class/console//loglevel > + > +Setting below minimum_console_loglevel fails > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +If you get an error when trying to set a loglevel, check the system-wide > +minimum:: > + > + cat /proc/sys/kernel/console_loglevel > + > +Per-console loglevels cannot be set below this minimum. This is a safety > +feature to ensure critical messages are always visible. > + > +Edge cases > +~~~~~~~~~~ > + > +**Setting all consoles to high loglevels**: If you set all consoles to > +very high loglevels (e.g., 1 or 2), most messages won't appear anywhere. > +This is valid but probably not what you want. Keep at least one console > +at a reasonable level for monitoring. Keep in mind that all messages (regardless of loglevel) are always available to userspace via dmesg or syslogd. So saying "messages won't appear anywhere" is a bit misleading. John Ogness