On 25/02/2022 23:23, Sergey Senozhatsky wrote:
> On (22/02/25 13:16), Petr Mladek wrote:
>>
>> The result looks good to me. We could do it as a followup patch.
>
> Yup, sounds good to me. Thanks.
Cool, I also agree.
So Andrew: is there anything missing in order to get this patch merged?
If you p
On (22/02/25 13:16), Petr Mladek wrote:
>
> The result looks good to me. We could do it as a followup patch.
>
Yup, sounds good to me. Thanks.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Fri 2022-02-25 14:18:22, Sergey Senozhatsky wrote:
> IOW move console_flush_on_panic() handling out of panic_print_sys_info().
> console_flush_on_panic() isn't really related to "print sys info" stuff
> that panic_print_sys_info() does.
>
> Something like this may be:
>
> static void panic_pr
Correction:
On (22/02/25 14:18), Sergey Senozhatsky wrote:
> >
> > Or just split panic_printk_sys_info() into these two functions.
>
> Agreed. I also tend to think that panic_printk_sys_info() is needed anyway,
split
On (22/02/24 15:33), Petr Mladek wrote:
> > My bad! I did not spot the `return` at the end of the new branch.
> >
> > + if (console_flush) {
> > + if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
> > + console_flush_on_panic(CONSOLE_REPLAY_ALL);
> > +
On 24/02/2022 11:33, Petr Mladek wrote:
> [...]
> That said, I could live with the patch as is. I leave the decision
> to Andrew. Feel free to use:
>
> Reviewed-by: Petr Mladek
>
> Best Regards,
> Petr
Thanks a bunch Petr and Sergey for the reviews (and the tags).
I also vote to keep the patch
On Wed 2022-02-23 01:27:35, Sergey Senozhatsky wrote:
> On (22/02/22 11:10), Guilherme G. Piccoli wrote:
> > On 21/02/2022 23:06, Sergey Senozhatsky wrote:
> > > On (22/02/14 11:13), Guilherme G. Piccoli wrote:
> > > [...]
> > > By additional panic_print messages you mean that panic_print_sys_info(
Hi,
On (22/02/23 10:15), Guilherme G. Piccoli wrote:
> On 22/02/2022 22:27, Sergey Senozhatsky wrote:
> > [...]
> > Hmm. Yeah, well, that's a bit of a tricky interface now
> >
> > panic()
> > // everything (if corresponding bits set), no console flush
> > panic_print_s
On 22/02/2022 22:27, Sergey Senozhatsky wrote:
> [...]
> Hmm. Yeah, well, that's a bit of a tricky interface now
>
> panic()
> // everything (if corresponding bits set), no console flush
> panic_print_sys_info(false)
> ...
> // console
On 23/02/2022 08:41, Sergey Senozhatsky wrote:
> On (22/02/15 17:14), Petr Mladek wrote:
>> Makes sense and looks good to me.
>>
>> Reviewed-by: Petr Mladek
>
> FWIW
>
> Reviewed-by: Sergey Senozhatsky
Thanks a lot Sergey, for your review =)
Andrew, do I need to send a V7 with the above tag o
On (22/02/15 17:14), Petr Mladek wrote:
> Makes sense and looks good to me.
>
> Reviewed-by: Petr Mladek
FWIW
Reviewed-by: Sergey Senozhatsky
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On (22/02/22 11:08), Guilherme G. Piccoli wrote:
> Hi Sergey, thanks for your feedback. So, personally I prefer having the
> flag - for me it's clear, it's just a matter of reading the prototype -
> either we print the info _or_ we console_flush.
>
> But let's see if others have a preference - if
On (22/02/22 11:10), Guilherme G. Piccoli wrote:
> On 21/02/2022 23:06, Sergey Senozhatsky wrote:
> > On (22/02/14 11:13), Guilherme G. Piccoli wrote:
> > [...]
> > By additional panic_print messages you mean that panic_print_sys_info()
> > will print everything (except PANIC_PRINT_ALL_PRINTK_MSG)
On 21/02/2022 23:06, Sergey Senozhatsky wrote:
> On (22/02/14 11:13), Guilherme G. Piccoli wrote:
> [...]
> By additional panic_print messages you mean that panic_print_sys_info()
> will print everything (except PANIC_PRINT_ALL_PRINTK_MSG) twice?
>
> Do we really need to dump everything twice? sho
On 21/02/2022 22:45, Sergey Senozhatsky wrote:
> [...]
> Yeah, if Petr is fine with that then I'm OK. But at the same time,
> we have `panic_print' which is a bit mask of what panic_print_sys_info()
> should do. And now we also have a boolean `console_flush` flag that tells
> panic_print_sys_info()
A trivial typo:
On (22/02/22 11:06), Sergey Senozhatsky wrote:
> @@ -286,6 +289,8 @@ void panic(const char *fmt, ...)
>*/
> atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
>
>
> + panic_print_sys_info(panic_print & ~PANIC_PRINT_ALL_PRINTK_MSG);
>
>
> kmsg_dump
On (22/02/14 11:13), Guilherme G. Piccoli wrote:
>
> The additional messages from panic_print could overwrite the oldest
> messages when the buffer is full. The only reasonable solution is to
> use a large enough log buffer, hence we added an advice into the kernel
> parameters documentation about
On (22/02/14 11:13), Guilherme G. Piccoli wrote:
> -static void panic_print_sys_info(void)
> +static void panic_print_sys_info(bool console_flush)
> {
> - if (panic_print & PANIC_PRINT_ALL_PRINTK_MSG)
> - console_flush_on_panic(CONSOLE_REPLAY_ALL);
> + if (console_flush) {
> +
On Mon 2022-02-14 11:13:09, Guilherme G. Piccoli wrote:
> The panic_print setting allows users to collect more information in a
> panic event, like memory stats, tasks, CPUs backtraces, etc.
> This is an interesting debug mechanism, but currently the print event
> happens *after* kmsg_dump(), meani
The panic_print setting allows users to collect more information in a
panic event, like memory stats, tasks, CPUs backtraces, etc.
This is an interesting debug mechanism, but currently the print event
happens *after* kmsg_dump(), meaning that pstore, for example, cannot
collect a dmesg with the pan
20 matches
Mail list logo
