[PATCH] docs: panic: Disclaimer about console verbosity when using panic_print with pstore

[PATCH] docs: panic: Disclaimer about console verbosity when using panic_print with pstore

[Guilherme G. Piccoli]

Users of panic_print / panic_sys_info are usually aware of the potentially
huge amount of information displayed with such options - their goal by
using them is indeed to dump more information during panic!

What might come unnoticed at first is the impact that the console_verbose()
call on panic path has, specially in cases that users rely on pstore as
a means to collect the panic logs. Recent experience shows that dumping
all tasks in an ARM64 system (with qcom_geni tty driver) gets a 2 minute
delay on panic time due to writing such information to console. But in
that case, pstore was used, so there was no need for console printing,
and suppressing that reduced the full time to less than 1 second.

The option "printk.console_no_auto_verbose" aims exactly at this use
case: avoid automatically increasing the loglevel during panic path.
So, let's officially document this to avoid users wasting their time
either on long panic printing or debugging the panic delays.

Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22..04c0ef2cf910 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4862,6 +4862,9 @@ Kernel parameters
 			so there are risks of losing older messages in the log.
 			Use this option carefully, maybe worth to setup a
 			bigger log buffer with "log_buf_len" along with this.
+			Also consider using "printk.console_no_auto_verbose=Y"
+			if using this along with pstore, to avoid extra delays
+			due to increased console verbosity during panic.
 
 	panic_sys_info= A comma separated list of extra information to be dumped
                         on panic.
@@ -4877,6 +4880,8 @@ Kernel parameters
                         blocked_tasks:  print only tasks in uninterruptible (blocked) state
 
                         This is a human readable alternative to the 'panic_print' option.
+                        Please be aware of the caveats using this option, check
+                        the panic_print information above regarding delays.
 
 	panic_console_replay
 			When panic happens, replay all kernel messages on
-- 
2.50.1

Re: [PATCH] docs: panic: Disclaimer about console verbosity when using panic_print with pstore

[Bradley Morgan]

I like this..

Reviewed-by: Bradley Morgan <include@grrlz.net>


Thanks!

Re: [PATCH] docs: panic: Disclaimer about console verbosity when using panic_print with pstore

[Feng Tang]

On Wed, Aug 05, 2026 at 05:49:04PM -0300, Guilherme G. Piccoli wrote:
> Users of panic_print / panic_sys_info are usually aware of the potentially
> huge amount of information displayed with such options - their goal by
> using them is indeed to dump more information during panic!
> 
> What might come unnoticed at first is the impact that the console_verbose()
> call on panic path has, specially in cases that users rely on pstore as
> a means to collect the panic logs. Recent experience shows that dumping
> all tasks in an ARM64 system (with qcom_geni tty driver) gets a 2 minute

Indeed, the all task call stack dumping is quite chatty :) which is
usually my last resort for debugging.

> delay on panic time due to writing such information to console. But in
> that case, pstore was used, so there was no need for console printing,
> and suppressing that reduced the full time to less than 1 second.
> 
> The option "printk.console_no_auto_verbose" aims exactly at this use
> case: avoid automatically increasing the loglevel during panic path.
> So, let's officially document this to avoid users wasting their time
> either on long panic printing or debugging the panic delays.
> 
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>

Reviewed-by: Feng Tang <feng.tang@linux.alibaba.com>

Thanks,
Feng

> ---
>  Documentation/admin-guide/kernel-parameters.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index b5493a7f8f22..04c0ef2cf910 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4862,6 +4862,9 @@ Kernel parameters
>  			so there are risks of losing older messages in the log.
>  			Use this option carefully, maybe worth to setup a
>  			bigger log buffer with "log_buf_len" along with this.
> +			Also consider using "printk.console_no_auto_verbose=Y"
> +			if using this along with pstore, to avoid extra delays
> +			due to increased console verbosity during panic.
>  
>  	panic_sys_info= A comma separated list of extra information to be dumped
>                          on panic.
> @@ -4877,6 +4880,8 @@ Kernel parameters
>                          blocked_tasks:  print only tasks in uninterruptible (blocked) state
>  
>                          This is a human readable alternative to the 'panic_print' option.
> +                        Please be aware of the caveats using this option, check
> +                        the panic_print information above regarding delays.
>  
>  	panic_console_replay
>  			When panic happens, replay all kernel messages on
> -- 
> 2.50.1

Re: [PATCH] docs: panic: Disclaimer about console verbosity when using panic_print with pstore

[Petr Mladek]

On Wed 2026-08-05 17:49:04, Guilherme G. Piccoli wrote:
> Users of panic_print / panic_sys_info are usually aware of the potentially
> huge amount of information displayed with such options - their goal by
> using them is indeed to dump more information during panic!
> 
> What might come unnoticed at first is the impact that the console_verbose()
> call on panic path has, specially in cases that users rely on pstore as
> a means to collect the panic logs. Recent experience shows that dumping
> all tasks in an ARM64 system (with qcom_geni tty driver) gets a 2 minute
> delay on panic time due to writing such information to console. But in
> that case, pstore was used, so there was no need for console printing,
> and suppressing that reduced the full time to less than 1 second.
> 
> The option "printk.console_no_auto_verbose" aims exactly at this use
> case: avoid automatically increasing the loglevel during panic path.
> So, let's officially document this to avoid users wasting their time
> either on long panic printing or debugging the panic delays.

Make sense. Few nits below.

> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
> ---
>  Documentation/admin-guide/kernel-parameters.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index b5493a7f8f22..04c0ef2cf910 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4862,6 +4862,9 @@ Kernel parameters
>  			so there are risks of losing older messages in the log.
>  			Use this option carefully, maybe worth to setup a
>  			bigger log buffer with "log_buf_len" along with this.
> +			Also consider using "printk.console_no_auto_verbose=Y"
> +			if using this along with pstore, to avoid extra delays
> +			due to increased console verbosity during panic.

The long blobs of text are hard to read. I would use this opportunity
to add some blank lines, for example:

<proposal>
	panic_print=	Bitmask for printing system info when panic happens.
			User can chose combination of the following bits:

			bit 0: print all tasks info
			bit 1: print system memory info
			bit 2: print timer info
			bit 3: print locks info if CONFIG_LOCKDEP is on
			bit 4: print ftrace buffer
			bit 5: replay all kernel messages on consoles at the end of panic
			bit 6: print all CPUs backtrace (if available in the arch)
			bit 7: print only tasks in uninterruptible (blocked) state

			*Be aware* that this option may print a _lot_ of lines.

			There is an increased risk of losing older messages in
			the log. Maybe worth to setup a bigger log buffer with
			"log_buf_len" along with this.

			Also consider using "printk.console_no_auto_verbose=Y"
			if using this along with pstore, to avoid extra delays
			due to increased console verbosity during panic.
</proposal>

>  
>  	panic_sys_info= A comma separated list of extra information to be dumped
>                          on panic.
> @@ -4877,6 +4880,8 @@ Kernel parameters
>                          blocked_tasks:  print only tasks in uninterruptible (blocked) state
>  
>                          This is a human readable alternative to the 'panic_print' option.
> +                        Please be aware of the caveats using this option, check
> +                        the panic_print information above regarding delays.

This is too focused on the "delays" problem. I would write it a
generic way:

<proposal>
			Please be aware of the caveats using this option, see
			the 'panic_print' option for more details.
</proposal>

>  	panic_console_replay
>  			When panic happens, replay all kernel messages on

Best Regards,
Petr

Re: [PATCH] docs: panic: Disclaimer about console verbosity when using panic_print with pstore

[Guilherme G. Piccoli]

On 19/08/2026 10:52, Petr Mladek wrote:
> [...]
> 
> Make sense. Few nits below.
> ...


> 
> The long blobs of text are hard to read. I would use this opportunity
> to add some blank lines, for example:
>


>  [...]
> This is too focused on the "delays" problem. I would write it a
> generic way:
> 
> <proposal>
> 			Please be aware of the caveats using this option, see
> 			the 'panic_print' option for more details.
> </proposal>


Thanks a bunch Petr, I liked your suggestions a lot, and already
implemented them in the V2:
https://lore.kernel.org/r/20260819183419.2203903-1-gpiccoli@igalia.com/

I've added your name as Suggested-by - hope you don't mind, lemme know
otherwise.
Cheers,


Guilherme