On Wed 2022-04-27 19:49:16, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
>
> But there is also an odd set of architecture calls
On Wed 2022-04-27 19:49:16, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
>
> But there is also an odd set of architecture calls
On Wed 2022-04-27 19:49:15, Guilherme G. Piccoli wrote:
> This patch renames the panic_notifier_list to panic_pre_reboot_list;
> the idea is that a subsequent patch will refactor the panic path
> in order to better split the notifiers, running some of them very
> early, some of them not so early
On Wed 2022-04-27 19:49:15, Guilherme G. Piccoli wrote:
> This patch renames the panic_notifier_list to panic_pre_reboot_list;
> the idea is that a subsequent patch will refactor the panic path
> in order to better split the notifiers, running some of them very
> early, some of them not so early
On Wed 2022-04-27 19:49:14, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to
> register callbacks to run earlier in the panic path than they
> currently do. This aims at informational mechanisms, like dumping
> kernel offsets and showing device error data
On Wed 2022-04-27 19:49:14, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to
> register callbacks to run earlier in the panic path than they
> currently do. This aims at informational mechanisms, like dumping
> kernel offsets and showing device error data
On Wed 2022-04-27 19:49:13, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to register
> callbacks to run very early in the panic path. This aims hypervisor/FW
> notification mechanisms as well as simple LED functions, and any other
> simple and safe
On Wed 2022-04-27 19:49:13, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to register
> callbacks to run very early in the panic path. This aims hypervisor/FW
> notification mechanisms as well as simple LED functions, and any other
> simple and safe
On Sun 2022-05-15 19:47:39, Guilherme G. Piccoli wrote:
> On 12/05/2022 11:03, Petr Mladek wrote:
> > This talks only about kdump. The reality is much more complicated.
> > The level affect the order of:
> >
> > + notifiers vs. kdump
> > + notifiers vs. c
On Sun 2022-05-15 19:47:39, Guilherme G. Piccoli wrote:
> On 12/05/2022 11:03, Petr Mladek wrote:
> > This talks only about kdump. The reality is much more complicated.
> > The level affect the order of:
> >
> > + notifiers vs. kdump
> > + notifiers vs. c
Hello,
first, I am sorry for stepping into the discussion so late.
I was busy with some other stuff and this patchset is far
from trivial.
Second, thanks a lot for putting so much effort into it.
Most of the changes look pretty good, especially all
the fixes of particular notifiers and split
Hello,
first, I am sorry for stepping into the discussion so late.
I was busy with some other stuff and this patchset is far
from trivial.
Second, thanks a lot for putting so much effort into it.
Most of the changes look pretty good, especially all
the fixes of particular notifiers and split
On Wed 2022-04-27 19:49:11, Guilherme G. Piccoli wrote:
> Currently the tracing dump_on_oops feature is implemented
> through separate notifiers, one for die/oops and the other
> for panic. With the addition of panic notifier "id", this
> patch makes use of such "id" to unify both functions.
>
>
On Wed 2022-04-27 19:49:11, Guilherme G. Piccoli wrote:
> Currently the tracing dump_on_oops feature is implemented
> through separate notifiers, one for die/oops and the other
> for panic. With the addition of panic notifier "id", this
> patch makes use of such "id" to unify both functions.
>
>
On Tue 2022-05-10 21:46:38, John Ogness wrote:
> On 2022-05-10, Steven Rostedt wrote:
> >> As already mentioned in the other reply, panic() sometimes stops the
> >> other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
> >>
> >> Another situation is when the CPU using the lock ends
On Tue 2022-05-10 21:46:38, John Ogness wrote:
> On 2022-05-10, Steven Rostedt wrote:
> >> As already mentioned in the other reply, panic() sometimes stops the
> >> other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus().
> >>
> >> Another situation is when the CPU using the lock ends
On Wed 2022-04-27 19:49:09, Guilherme G. Piccoli wrote:
> This patch improves the panic/die notifiers in this driver by
> making use of a passed "id" instead of comparing pointer
> address; also, it removes an useless prototype declaration
> and unnecessary header inclusion.
>
> This is part of a
On Wed 2022-04-27 19:49:09, Guilherme G. Piccoli wrote:
> This patch improves the panic/die notifiers in this driver by
> making use of a passed "id" instead of comparing pointer
> address; also, it removes an useless prototype declaration
> and unnecessary header inclusion.
>
> This is part of a
On Wed 2022-04-27 19:49:08, Guilherme G. Piccoli wrote:
> The notifiers infrastructure provides a way to pass an "id" to the
> callbacks to determine what kind of event happened, i.e., what is
> the reason behind they getting called.
>
> The panic notifier currently pass 0, but this is soon to be
On Wed 2022-04-27 19:49:08, Guilherme G. Piccoli wrote:
> The notifiers infrastructure provides a way to pass an "id" to the
> callbacks to determine what kind of event happened, i.e., what is
> the reason behind they getting called.
>
> The panic notifier currently pass 0, but this is soon to be
On Wed 2022-04-27 19:49:05, Guilherme G. Piccoli wrote:
> Currently the panic notifiers from user mode linux don't follow
> the convention for most of the other notifiers present in the
> kernel (indentation, priority setting, numeric return).
> More important, the priorities could be improved,
On Wed 2022-04-27 19:49:05, Guilherme G. Piccoli wrote:
> Currently the panic notifiers from user mode linux don't follow
> the convention for most of the other notifiers present in the
> kernel (indentation, priority setting, numeric return).
> More important, the priorities could be improved,
hese architectures are used to.
Anyway, it makes sense to do this as the last notifier after
dumping other information.
Reviewed-by: Petr Mladek
Best Regards,
Petr
hese architectures are used to.
Anyway, it makes sense to do this as the last notifier after
dumping other information.
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://
On Wed 2022-04-27 19:48:59, Guilherme G. Piccoli wrote:
> The pvpanic driver relies on panic notifiers to execute a callback
> on panic event. Such function is executed in atomic context - the
> panic function disables local IRQs, preemption and all other CPUs
> that aren't running the panic code.
On Wed 2022-04-27 19:48:59, Guilherme G. Piccoli wrote:
> The pvpanic driver relies on panic notifiers to execute a callback
> on panic event. Such function is executed in atomic context - the
> panic function disables local IRQs, preemption and all other CPUs
> that aren't running the panic code.
On Tue 2022-05-03 16:12:09, Guilherme G. Piccoli wrote:
> On 03/05/2022 15:03, Evan Green wrote:
> > [...]
> > gsmi_shutdown_reason() is a common function called in other scenarios
> > as well, like reboot and thermal trip, where it may still make sense
> > to wait to acquire a spinlock. Maybe we
On Tue 2022-05-03 16:12:09, Guilherme G. Piccoli wrote:
> On 03/05/2022 15:03, Evan Green wrote:
> > [...]
> > gsmi_shutdown_reason() is a common function called in other scenarios
> > as well, like reboot and thermal trip, where it may still make sense
> > to wait to acquire a spinlock. Maybe we
On Mon 2022-03-07 11:25:30, Guilherme G. Piccoli wrote:
> On 07/03/2022 11:04, b...@redhat.com wrote:
> > [...]
> > Ah, sorry, I even didn't notice that. That's awesome if we can make use
> > of that. While I still have concerns:
> >
>
> Thanks, nice that you liked the idea.
>
> > 1) about
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
hese lists cause merge and backporting conflicts. I vote to avoid
this approach ;-)
> panic()
> panic_print_sys_info(panic_print & EARLY_PANIC_MASK)
> ...
> panic_print_sys_info(panic_print & LATE_PANIC_MASK)
That said, I could li
e we added an advice into the kernel
> parameters documentation about that.
>
> Cc: Feng Tang
> Cc: Petr Mladek
> Acked-by: Baoquan He
> Signed-off-by: Guilherme G. Piccoli
Makes sense and looks good to me.
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Thu 2022-01-27 14:16:20, Guilherme G. Piccoli wrote:
> On 25/01/2022 10:06, d.hatay...@fujitsu.com wrote:
> >
> > But the pre_dump cannot avoid calling multiple unnecessary handlers, right?
> > It's more risky than the previous idea...
> >
>
> I think we could have 2 kernel parameters then:
On Wed 2022-01-26 11:10:39, Baoquan He wrote:
> On 01/24/22 at 11:48am, Guilherme G. Piccoli wrote:
> > On 24/01/2022 10:59, Baoquan He wrote:
> > > [...]
> > > About pre_dump, if the dump is crash dump, hope those pre_dump notifiers
> > > will be executed under conditional check, e.g only if
> >
On Mon 2022-01-24 16:57:17, Michael Kelley (LINUX) wrote:
> From: Baoquan He Sent: Friday, January 21, 2022 8:34 PM
> >
> > On 01/21/22 at 03:00pm, Michael Kelley (LINUX) wrote:
> > > From: Baoquan He Sent: Thursday, January 20, 2022 6:31
> > > PM
> > > >
> > > > On 01/20/22 at 06:36pm,
Adding some more people into Cc. Some modified the logic in the past.
Some are familiar with some interesting areas where the panic
notfiers are used.
On Sat 2022-01-08 12:34:51, Guilherme G. Piccoli wrote:
> The kernel notifier infrastructure allows function callbacks to be
> added in multiple
On Wed 2022-01-19 13:03:15, Guilherme G. Piccoli wrote:
> Thanks again Petr, for the deep analysis! Much appreciated.
> Some comments inline below:
>
>
> On 19/01/2022 12:48, Petr Mladek wrote:
> >[...]
> > From my POV, the function of panic notifiers is not well d
.
> [0] https://lore.kernel.org/lkml/20211230161828.121858-1-gpicc...@igalia.com
> [1]
> https://lore.kernel.org/lkml/f25672a4-e4dd-29e8-b2db-f92dd9ff9...@igalia.com
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=5613b7538f69
linux-next is re
On Wed 2022-01-19 15:13:18, Baoquan He wrote:
> On 01/14/22 at 03:30pm, 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 a pretty interesting debug mechanism, but
On Thu 2022-01-13 12:15:08, Guilherme G. Piccoli wrote:
> On 13/01/2022 11:22, Petr Mladek wrote:
> > [...]
> > OK, do we have any specific reason why panic_print_sys_info()
> > should get called right before kmsg_dump() when this code patch
> > is used?
> >
On Thu 2022-01-13 09:34:01, Guilherme G. Piccoli wrote:
> On 13/01/2022 08:50, Petr Mladek wrote:
> >> @@ -249,7 +252,7 @@ void panic(const char *fmt, ...)
> >> * show some extra information on kernel log if it was set...
> >> */
On Thu 2022-01-06 18:28:35, 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 a pretty interesting debug mechanism, but currently the print
> event happens *after*
On Mon 2022-01-03 13:30:35, Guilherme G. Piccoli wrote:
> Hi Petr, first of all, I'd like to thank you for the _very_ complete and
> informative response, pretty useful!
> Some comments inline below:
>
>
> On 03/01/2022 11:58, Petr Mladek wrote:
> > [...]
> >
On Thu 2021-12-30 13:18:28, 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 a pretty interesting debug mechanism, but currently the print
> event happens *after*
On Wed 2021-11-10 10:37:26, Daniel Vetter wrote:
> On Tue, Nov 09, 2021 at 10:38:47PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 09, 2021 at 12:06:48PM -0800, Sultan Alsawaf wrote:
> > > Hi,
> > >
> > > I encountered a printk deadlock on 5.13 which appears to still affect the
> > > latest
> >
On Mon 2021-10-18 22:02:03, Steven Rostedt wrote:
> On Mon, 18 Oct 2021 12:19:20 +0200
> Petr Mladek wrote:
>
> > > -
> > > bit = trace_get_context_bit() + start;
> > > if (unlikely(val & (1 << bit))) {
> > > /*
> > >
On Mon 2021-10-18 09:50:27, Steven Rostedt wrote:
> On Mon, 18 Oct 2021 12:19:20 +0200
> Petr Mladek wrote:
>
> > On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> > > From: "Steven Rostedt (VMware)"
> > >
> > > While writing an e
On Fri 2021-10-15 11:00:35, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> While writing an email explaining the "bit = 0" logic for a discussion on
> making ftrace_test_recursion_trylock() disable preemption, I discovered a
> path that makes the "not do the logic if bit is zero"
On Fri 2021-10-15 11:13:08, 王贇 wrote:
>
>
> On 2021/10/14 下午11:14, Petr Mladek wrote:
> [snip]
> >> - return trace_test_and_set_recursion(ip, parent_ip, TRACE_FTRACE_START,
> >> TRACE_FTRACE_MAX);
> >> + int bit;
> >> +
> >
> + if (bit)
This is not symetric with trylock(). It should be:
if (bit > 0)
Anyway, trace_clear_recursion() quiently ignores bit != 0
> + preempt_enable_notrace();
> trace_clear_recursion(bit);
> }
Below is my proposed patch that tries to better explain the recursion
check:
>
On Tue 2021-08-03 15:18:51, John Ogness wrote:
> Hi,
>
> This is the next part of our printk-rework effort (points 3 and
> 4 of the LPC 2019 summary [0]).
>
> Here the concept of "atomic consoles" is introduced through a
> new (optional) write_atomic() callback for console drivers. This
>
On Tue 2021-08-03 15:18:51, John Ogness wrote:
> Hi,
>
> This is the next part of our printk-rework effort (points 3 and
> 4 of the LPC 2019 summary [0]).
>
> Here the concept of "atomic consoles" is introduced through a
> new (optional) write_atomic() callback for console drivers. This
>
On Tue 2021-08-03 17:36:32, John Ogness wrote:
> On 2021-08-03, Daniel Thompson wrote:
> > On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> >> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
> >> during cpu roundup. This will conflict with the printk cpulock.
> >
On Wed 2021-08-04 12:31:59, Daniel Thompson wrote:
> On Tue, Aug 03, 2021 at 05:36:32PM +0206, John Ogness wrote:
> > On 2021-08-03, Daniel Thompson wrote:
> > > On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> > >> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
On Tue 2021-08-03 17:36:32, John Ogness wrote:
> On 2021-08-03, Daniel Thompson wrote:
> > On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> >> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
> >> during cpu roundup. This will conflict with the printk cpulock.
> >
On Wed 2021-08-04 12:31:59, Daniel Thompson wrote:
> On Tue, Aug 03, 2021 at 05:36:32PM +0206, John Ogness wrote:
> > On 2021-08-03, Daniel Thompson wrote:
> > > On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
> > >> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
On Thu 2021-07-15 21:39:53, John Ogness wrote:
> Hi,
>
> Here is v4 of a series to remove the safe buffers. v3 can be
> found here [0]. The safe buffers are no longer needed because
> messages can be stored directly into the log buffer from any
> context.
>
> However, the safe buffers also
On Thu 2021-07-15 21:39:53, John Ogness wrote:
> Hi,
>
> Here is v4 of a series to remove the safe buffers. v3 can be
> found here [0]. The safe buffers are no longer needed because
> messages can be stored directly into the log buffer from any
> context.
>
> However, the safe buffers also
On Wed 2021-07-21 14:52:15, John Ogness wrote:
> On 2021-07-21, Petr Mladek wrote:
> >> --- a/kernel/trace/trace.c
> >> +++ b/kernel/trace/trace.c
> >> @@ -9647,7 +9647,7 @@ void ftrace_dump(enum ftrace_dump_mode
> >> oops_dump_mode)
> >>tr
On Thu 2021-07-15 21:39:57, John Ogness wrote:
> All NMI contexts are handled the same as the safe context: store the
> message and defer printing. There is no need to have special NMI
> context tracking for this. Using in_nmi() is enough.
>
> There are several parts of the kernel that are
for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console and console_owner locks is left
> in place. This is because the console and console_owner locks are
> needed for the actual printing.
>
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
Best Regards,
Petr
for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console and console_owner locks is left
> in place. This is because the console and console_owner locks are
> needed for the actual printing.
>
> Signed-off-by: John Ogness
On Thu 2021-06-24 17:41:56, John Ogness wrote:
> I would prefer a v4 with these fixes:
>
> - wrap @console_owner_lock with printk_safe usage
>
> - remove unnecessary printk_safe usage from printk_safe.c
>
> - update commit message to say that safe context tracking is left in
> place for both
On Thu 2021-06-24 13:17:46, John Ogness wrote:
> All NMI contexts are handled the same as the safe context: store the
> message and defer printing. There is no need to have special NMI
> context tracking for this. Using in_nmi() is enough.
>
> Signed-off-by: John Ogness
>
On Thu 2021-06-24 17:41:56, John Ogness wrote:
> I would prefer a v4 with these fixes:
>
> - wrap @console_owner_lock with printk_safe usage
>
> - remove unnecessary printk_safe usage from printk_safe.c
>
> - update commit message to say that safe context tracking is left in
> place for both
for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console lock is left in place. This is
> because the console lock is needed for the actual printing.
Feel free to use:
Reviewed-by: Petr Mladek
There are some comments below.
> --- a/kernel/prin
for most of printk is not needed. Remove it. Only safe context
> tracking relating to the console lock is left in place. This is
> because the console lock is needed for the actual printing.
Feel free to use:
Reviewed-by: Petr Mladek
There are some comments below.
> --- a/kernel/prin
On Mon 2021-05-17 08:21:12, Geert Uytterhoeven wrote:
> On Wed, Mar 31, 2021 at 11:59 AM Geert Uytterhoeven
> wrote:
> > While long fancy messages have a higher probability of being seen than
> > small messages, they may scroll of the screen fast, if visible at all,
> > and may still be missed.
y: Andy Shevchenko
Reviewed-by: Petr Mladek
I am going to queue the entire patchset for 5.14 via the printk tree
the following week unless anyone complains in the meantime.
Best Regards,
Petr
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sou
On Mon 2021-05-10 18:04:10, Andy Shevchenko wrote:
> ISO 8601 defines 'T' as a separator between date and time. Though,
> some ABIs use time and date with ' ' separator instead.
>
> Add a flavour to the %pt specifier to override default separator.
>
> Signed-off-by: Andy Shevchenko
> ---
>
rnel.org
> Signed-off-by: Andy Shevchenko
Reviewed-by: Petr Mladek
Best Regards,
Petr
___
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
On Mon 2021-05-10 18:04:13, Andy Shevchenko wrote:
> Use %ptTs instead of open coded variant to print contents
> of time64_t type in human readable form.
>
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Signed-off-by: Andy Shevchenko
Reviewed-by: Petr Mladek
On Mon 2021-05-10 18:04:11, Andy Shevchenko wrote:
> Use %ptTs instead of open-coded variant to print contents
> of time64_t type in human readable form.
>
> Cc: Jason Wessel
> Cc: Daniel Thompson
> Cc: kgdb-bugreport@lists.sourceforge.net
> Signed-off-by: Andy Shevchenk
On Tue 2021-05-11 12:58:47, David Laight wrote:
> From: Steven Rostedt
> > Sent: 11 May 2021 13:53
> >
> > On Tue, 11 May 2021 12:36:06 +
> > David Laight wrote:
> >
> > > > x1 : ff93fef15788 x0 : ffe3622352e0
> > > > Call trace:
> > > > lkdtm_WARNING+0x28/0x30 [lkdtm
> > > >
On Mon 2021-05-10 17:38:32, Stephen Boyd wrote:
> This series adds the kernel's build ID[1] to the stacktrace header
> printed in oops messages, warnings, etc. and the build ID for any module
> that appears in the stacktrace after the module name. The goal is to
> make the stacktrace more
On Mon 2021-04-19 09:27:43, Rasmus Villemoes wrote:
> On 16/04/2021 15.56, Chris Down wrote:
> > Hey Petr, Rasmus,
>
> >> This is great point! There are many other subsystem specific wrappers,
> >> e,g, ata_dev_printk(), netdev_printk(), snd_printk(), dprintk().
> >> We should make it easy to
On Tue 2021-04-13 15:57:49, Stephen Boyd wrote:
> Quoting Petr Mladek (2021-04-13 08:01:14)
> > On Fri 2021-04-09 18:52:52, Stephen Boyd wrote:
> > > Let's make kernel stacktraces easier to identify by including the build
> > > ID[1] of a module if the stacktrace is prin
On Tue 2021-04-13 17:22:46, Samo Pogačnik wrote:
> Dne 13.04.2021 (tor) ob 16:32 +0200 je Petr Mladek napisal(a):
> > On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote:
> > > Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a):
> > > > On Mon 2021-04-12
On Tue 2021-04-13 13:56:31, Andy Shevchenko wrote:
> On Mon, Apr 12, 2021 at 12:29:05PM -0700, Stephen Boyd wrote:
> > Quoting Andy Shevchenko (2021-04-12 04:58:02)
> > > On Fri, Apr 09, 2021 at 06:52:52PM -0700, Stephen Boyd wrote:
> > > > Let's make kernel stacktraces easier to identify by
On Fri 2021-04-09 18:52:52, Stephen Boyd wrote:
> Let's make kernel stacktraces easier to identify by including the build
> ID[1] of a module if the stacktrace is printing a symbol from a module.
> This makes it simpler for developers to locate a kernel module's full
> debuginfo for a particular
c229de205662d5a9e0d4c580f19a1 is the build ID,
> following the kernel version number. Put it all behind a config option,
> STACKTRACE_BUILD_ID, so that kernel developers can remove this
> information if they decide it is too much.
>
> Cc: Jiri Olsa
> Cc: Alexei Starovoitov
>
Data size Description
> Xen0x0008 Unknown note type: (0x0003) description data: 00 00
> 00 ff80
>
> Let's make sure that it is a GNU note when parsing the build ID so that
> we can use this function to parse a vmlinux's build ID
On Tue 2021-04-13 13:10:50, Samo Pogačnik wrote:
> Dne 13.04.2021 (tor) ob 11:41 +0200 je Petr Mladek napisal(a):
> > On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> > > Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > > > What is the in
On Mon 2021-04-12 14:41:27, Samo Pogačnik wrote:
> Dne 12.04.2021 (pon) ob 19:39 +0900 je Tetsuo Handa napisal(a):
> > What is the intended usage of /dev/ttyprintk ?
> >
>
> The intended use of 'ttyprintk' is to redirect console to /dev/ttyprintk
> via the TIOCCONS ioctl. After successfull
On Sun 2021-04-11 14:08:14, Joe Perches wrote:
> On Sun, 2021-04-11 at 21:52 +0200, John Ogness wrote:
> > I'd rather fix dev_info callers to allow pr_cont and then fix any code
> > that is using this workaround.
>
> Assuming you mean all dev_() uses, me too.
>
> > And if the print maintainers
On Sun 2021-04-11 14:08:14, Joe Perches wrote:
> On Sun, 2021-04-11 at 21:52 +0200, John Ogness wrote:
> > I'd rather fix dev_info callers to allow pr_cont and then fix any code
> > that is using this workaround.
>
> Assuming you mean all dev_() uses, me too.
>
> > And if the print maintainers
On Sun 2021-04-11 21:52:59, John Ogness wrote:
> On 2021-04-11, Alexander Monakov wrote:
> >>> The second line is emitted via 'pr_cont', which causes it to have a
> >>> different ('warn') loglevel compared to the previous line ('info').
> >>>
> >>> Commit 9a295ff0ffc9 attempted to rectify this
On Sun 2021-04-11 21:52:59, John Ogness wrote:
> On 2021-04-11, Alexander Monakov wrote:
> >>> The second line is emitted via 'pr_cont', which causes it to have a
> >>> different ('warn') loglevel compared to the previous line ('info').
> >>>
> >>> Commit 9a295ff0ffc9 attempted to rectify this
On Thu 2021-04-08 12:52:27, Stephen Boyd wrote:
> Quoting Petr Mladek (2021-04-08 03:13:20)
> > It helped with the vmlinux buildid. I see the following:
> >
> > [ 551.435942][ T1803] test_printf: loaded.
> > [ 551.436667][ T1803] [ cut here ]---
On Wed 2021-04-07 23:20:32, Stephen Boyd wrote:
> Quoting Petr Mladek (2021-04-07 07:03:19)
> > # readelf -Wn vmlinux-5.12.0-rc6-default+
> >
> > Displaying notes found in: .notes
> > Owner Data size Description
> > Xen
On Tue 2021-03-30 20:05:20, Stephen Boyd wrote:
> We can use the vmlinux_build_id array here now instead of open coding
> it. This mostly consolidates code.
>
> Cc: Jiri Olsa
> Cc: Alexei Starovoitov
> Cc: Jessica Yu
> Cc: Evan Green
> Cc: Hsin-Yi Wang
> Cc: Dave Young
> Cc: Baoquan He
>
On Tue 2021-03-30 20:05:20, Stephen Boyd wrote:
> We can use the vmlinux_build_id array here now instead of open coding
> it. This mostly consolidates code.
>
> Cc: Jiri Olsa
> Cc: Alexei Starovoitov
> Cc: Jessica Yu
> Cc: Evan Green
> Cc: Hsin-Yi Wang
> Cc: Dave Young
> Cc: Baoquan He
>
On Tue 2021-03-30 20:05:12, Stephen Boyd wrote:
> Let's make kernel stacktraces easier to identify by including the build
> ID[1] of a module if the stacktrace is printing a symbol from a module.
> This makes it simpler for developers to locate a kernel module's full
> debuginfo for a particular
On Tue 2021-03-30 20:05:12, Stephen Boyd wrote:
> Let's make kernel stacktraces easier to identify by including the build
> ID[1] of a module if the stacktrace is printing a symbol from a module.
> This makes it simpler for developers to locate a kernel module's full
> debuginfo for a particular
On Tue 2021-03-30 20:05:11, Stephen Boyd wrote:
> Add the running kernel's build ID[1] to the stacktrace information
> header. This makes it simpler for developers to locate the vmlinux with
> full debuginfo for a particular kernel stacktrace. Combined with
> scripts/decode_stracktrace.sh, a
On Tue 2021-03-30 20:05:11, Stephen Boyd wrote:
> Add the running kernel's build ID[1] to the stacktrace information
> header. This makes it simpler for developers to locate the vmlinux with
> full debuginfo for a particular kernel stacktrace. Combined with
> scripts/decode_stracktrace.sh, a
On Thu 2021-02-25 17:46:39, Vlastimil Babka wrote:
> We have several modifiers for plain pointers (%p, %px and %pK) and now also
> the no_hash_pointers boot parameter. The documentation should help to choose
> which variant to use. Importantly, we should discourage %px in favour of %p
> (with the
hdog: Modify the explanation related to watchdog thread
> doc: watchdog: Delete the explanation about "watchdog/%u".
> doc: watchdog: Modify the explanation related to watchdog thread
> doc: watchdog: Modify the doc related to "watchdog/%u"
All four patches make sense to me:
Reviewed-by: Petr Mladek
Best Regards,
Petr
On Tue 2021-04-06 21:10:48, Greg Kroah-Hartman wrote:
> On Wed, Apr 07, 2021 at 01:22:34AM +0900, Tetsuo Handa wrote:
> > On 2021/04/07 0:10, Petr Mladek wrote:
> > >> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> > >> index
On Fri 2021-04-02 11:14:18, Sergey Senozhatsky wrote:
> On (21/04/01 16:17), Petr Mladek wrote:
> > > For the long term, we should introduce a printk-context API that allows
> > > callers to perfectly pack their multi-line output into a single
> > > entry. We discus
301 - 400 of 9254 matches
Mail list logo
