From nobody Tue Dec 2 02:41:51 2025 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 334292E1F11 for ; Tue, 18 Nov 2025 19:08:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763492886; cv=none; b=YanOhKMDo0aEFlMVfwrVLB/aptPgn9QIT35RCw7GQfoM5qRHh2FCBMaSZrFsEvsdd25VB9MhkWETJFe2QhIsdhyU4oIzRMlg1YCqp1gU4UvZsO5OIirJUl/npPcQCSHyZXfncAgXNdXuFMtBmAMT/srx2sdmRsr6sfrpRCy6pOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763492886; c=relaxed/simple; bh=OqB8QsrlmQi+iJkS57ZcXLS461wspDc6oQWqwOU4/oc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=H/q4cymg2ZngzZBjyjdqZIZCo7dmGkEgr00X4fZlXKQlqlt87klxp7FX+hJQ/4nW2Rk4Z+h8E6d59M7H6uEiyQ9Ju85MlPOah1SYxhNG9O7idjYOmfqQHCz77R6hOVJ+tH0LfCviqSvBqDwGXzGe+5/Dod26vJ/bLLViSjHJhr8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=chrisdown.name; spf=pass smtp.mailfrom=chrisdown.name; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b=ZbaJuuAv; arc=none smtp.client-ip=209.85.216.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=chrisdown.name Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chrisdown.name Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="ZbaJuuAv" Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-34361025290so4493538a91.1 for ; Tue, 18 Nov 2025 11:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; t=1763492884; x=1764097684; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=rHOi0QL0/c3tomQ4yvX19ikD6nsO02TviKx8yiTQ0BU=; b=ZbaJuuAvJVvX9oWhMxs2BCqfXehstiUHxPjucO83ytnyyOp/ac+kxHTE/ZjTTxgAR0 HN7rvd3PEzd9wei3ckf0LaJgUahdjdjMF2ZtDGFVKtEXM5ko/3GUV4nVo/uGh5RJQ1Z6 kxzkak4kD9cMNyXkSNkl14HTr3xokrfjKVbGw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763492884; x=1764097684; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=rHOi0QL0/c3tomQ4yvX19ikD6nsO02TviKx8yiTQ0BU=; b=DYhvC7WLOoSuKf1VDRsSnB8Vl18h5BI+1QP9uw9bIe3yxDarp4O7cMvZtGTcStNs2O +wXyZwbI/h0EHFmOukcKpuwNVmx5yGheD0CD8Nk8ih7bpO8Hmm3YGBf0B1W05Pk+hKDU tYEXHBdlqzq9X396sjCc4Hw+4qoPWYKeaoNS4+4LM7a74PKDwlbN6A84IhTf4Mz38Yk4 y/xY7WzbWzqhQsvbOtyz1RkWAW3wLRvZZOerQfDSTQCifDtkVJs4YZbREwC4QuH8ePH3 DDdGNfxI6afOJCkkRVDuM9li9l5FgkpXUYby8T37hVVpycW+R4YN2hPgVbtoM6E5LR4h P5Ow== X-Gm-Message-State: AOJu0YyF2OTrHZoojbdSbcoaNNoOD45iH5r+7PfM9hTxeOx+8wzAb6ZX oANUbxTq71IiCuU1eT+thS2uHMzNtIdp6PNfY50u/+7UVskHAnUcVWw4hXxzy5vHNwE= X-Gm-Gg: ASbGnctQisJxSebSIW0/1eVc0rUTeaXlrvHvogQ7Mfy4vXgtMhamC2efx4ZMzAUVSGE QQyYNCfP1za+T3pvhCp/ShsZpW+1M1Uao4so3ANYtBWuioLBBeKC6KPXNk2po0X9DOa228gkAVK ED5/gRIrRV9Azti42y7PqB+nqIqY28QnLbZAYzR+DQCP0VblsAUmoXche20/7glRvjBJWQ4CUZH loRGVoGik2AwY630mcFIyathJkEhzrKkFaTrRyhQACOMxvqkyVH5j7KxhuE2+gfy9tkS1tUlwZj PeFUDWFPr4uja5p+XkS/dUHE9+K3UVD0R+L4dUXyMKwI1OJF/UQsNFhDKVlhjDQRpR3WyZdy4rE +gRsYllC4xzTHxSlWoufmYykCfsQZMrNdWlOwAiVLng+ed8Mir8qoipWwlEjNVI7ix5PasndkJr /8YWVDRyU+aU8iUPqg9H0= X-Google-Smtp-Source: AGHT+IHlgKTjklFL/yEZEbXkSwoZKTktvWTvfIgIU4+NHDm+JiNHiqkXErOT9pWqI14OMkdpvX6rag== X-Received: by 2002:a17:90b:38ca:b0:340:c151:2d66 with SMTP id 98e67ed59e1d1-343fa638ef3mr16475298a91.30.1763492884378; Tue, 18 Nov 2025 11:08:04 -0800 (PST) Received: from localhost ([116.86.198.140]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-345bbc17312sm246110a91.0.2025.11.18.11.08.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Nov 2025 11:08:03 -0800 (PST) Date: Wed, 19 Nov 2025 03:08:01 +0800 From: Chris Down To: Petr Mladek Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Sergey Senozhatsky , Steven Rostedt , John Ogness , Geert Uytterhoeven , Tony Lindgren , kernel-team@fb.com Subject: [PATCH v7 11/13] printk: docs: Add comprehensive guidance for per-console loglevels Message-ID: <60de5c9e249579d8d4e5a9423067157a462eb763.1763492585.git.chris@chrisdown.name> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.15 (2b349c5e) (2025-10-02) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The per-console loglevel feature documentation could use some practical guidance. This commit adds: - Examples section covering runtime configuration, effective loglevel checking, and boot-time configuration - Common use case demonstrating high-performance netconsole with quiet serial console fallback - Performance impact section explaining how per-console loglevels reduce latency by filtering messages before slow console writes - Troubleshooting section addressing common issues like messages not appearing, loglevel constraints, and minimum console loglevel - Edge cases section documenting behavior with concurrent writes, console unregistration, and global loglevel changes The guidance interleaves advice about many parts of this patchset, so let's have it in a distinct commit. This documentation will help users understand how to effectively use and debug per-console loglevels. Signed-off-by: Chris Down --- .../admin-guide/per-console-loglevel.rst | 152 ++++++++++++++++++ 1 file changed, 152 insertions(+) diff --git a/Documentation/admin-guide/per-console-loglevel.rst b/Documenta= tion/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 view= ed at This will be in effect if no other global control overrides it. Look at ``effective_loglevel`` and ``effective_loglevel_source`` to verify that. =20 +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 + +Set netconsole to show info and above (level 6):: + + echo 6 > /sys/class/console/netcon0/loglevel + +Reset a console to use the global loglevel:: + + echo -1 > /sys/class/console/ttyS0/loglevel + +Checking effective loglevel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check what loglevel is actually in effect for a console:: + + $ cat /sys/class/console/ttyS0/effective_loglevel + 4 + $ cat /sys/class/console/ttyS0/effective_loglevel_source + local + +If the source shows ``global``, the console is using the global loglevel. +If it shows ``local``, the console is using its per-console loglevel. +If it shows ``ignore_loglevel``, all loglevel controls are being ignored. + +Boot-time configuration +~~~~~~~~~~~~~~~~~~~~~~~~ + +Set different loglevels for different consoles at boot:: + + console=3DttyS0,115200n8,loglevel:3 console=3Dtty0,loglevel:5 + +This sets the serial console (ttyS0) to level 3 (KERN_ERR) and the VGA +console (tty0) to level 5 (KERN_NOTICE). + +For netconsole:: + + netconsole=3D@/,@192.168.1.1/ console=3Dnetcon0,loglevel:6 + +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 imp= act, +but still available for emergencies:: + + # Netconsole gets INFO and above (verbose) + echo 6 > /sys/class/console/netcon0/loglevel + + # Serial console gets only WARN and above (quiet, for emergencies) + echo 4 > /sys/class/console/ttyS0/loglevel + +This allows you to see informational messages on the fast netconsole witho= ut +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 befo= re +the console write callback is invoked. This eliminates the latency that wo= uld +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. + +Serial console writes can take tens of milliseconds per message. During +periods of heavy logging (e.g., during network debugging or block I/O trac= ing), +this can cause significant application-level stalls. By setting a higher +per-console loglevel for the serial console, you can avoid these stalls wh= ile +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, ALE= RT, + 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. + +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 alwa= ys +go to all consoles. To use the global loglevel, set the per-console loglev= el +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. + +**Console unregistration while sysfs file is open**: If a console is +unregistered (e.g., module unloaded) while you have its sysfs files open, +the files will become stale. Close and reopen them, or they will eventually +return errors. + +**Global loglevel changes**: If you change the global console_loglevel +via sysctl, consoles set to -1 (use global) will immediately reflect the +new level. Consoles with explicit per-console levels are unaffected. + Deprecated ~~~~~~~~~~ =20 --=20 2.51.2