On 2020-08-11, Nick Desaulniers wrote:
> From what I can tell, I think this patch ("printk: use the lockless
> ringbuffer") breaks lx-dmesg in CONFIG_GDB_SCRIPTS.
>
> (gdb) lx-dmesg
> Python Exception No symbol "log_first_idx" in specified
> context.:
> Error occurred in Python: No symbol "log_
>From what I can tell, I think this patch ("printk: use the lockless
ringbuffer") breaks lx-dmesg in CONFIG_GDB_SCRIPTS.
(gdb) lx-dmesg
Python Exception No symbol "log_first_idx" in specified
context.:
Error occurred in Python: No symbol "log_first_idx" in specified context.
This command is us
On Mon, 20 Jul 2020 at 12:20, John Ogness wrote:
>
> On 2020-07-18, Marco Elver wrote:
> > It seems this causes a regression observed at least with newline-only
> > printks.
> > [...]
> > -- >8 --
> >
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -1039,6 +1039,10 @@ asmlinkage __visi
On 2020-07-18, Marco Elver wrote:
> It seems this causes a regression observed at least with newline-only
> printks.
> [...]
> -- >8 --
>
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1039,6 +1039,10 @@ asmlinkage __visible void __init start_kernel(void)
> sfi_init_late();
> kc
On Mon, Jul 20, 2020 at 11:41 AM Marco Elver wrote:
>
> On Mon, 20 Jul 2020 at 10:41, Sergey Senozhatsky
> wrote:
> >
> > On (20/07/20 08:43), Marco Elver wrote:
> > > On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote:
> > >
> > > As I said, a number of debugging tools use them to f
On Mon, 20 Jul 2020 at 10:41, Sergey Senozhatsky
wrote:
>
> On (20/07/20 08:43), Marco Elver wrote:
> > On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote:
> >
> > As I said, a number of debugging tools use them to format reports to be
> > more readable (visually separate title and re
On (20/07/20 08:43), Marco Elver wrote:
> On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote:
>
> As I said, a number of debugging tools use them to format reports to be
> more readable (visually separate title and report body, and separate
> parts of the report). Also, such reports a
On (20/07/20 08:43), Marco Elver wrote:
[..]
> please see a full list of newline-print users below.
[..]
> $> git grep -En '\<(printk|pr_err|pr_warn|pr_info)\>\("\\n"\)'
> arch/alpha/kernel/core_wildfire.c:650:printk("\n");
> arch/alpha/kernel/core_wildfire.c:658:printk("\n");
> arc
On Mon, Jul 20, 2020 at 9:45 AM Marco Elver wrote:
> On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote:
> > On (20/07/18 14:10), Marco Elver wrote:
> > >
> > > It seems this causes a regression observed at least with newline-only
> > > printks. I noticed this during -next testing bec
On Sun, Jul 19, 2020 at 12:43PM +0900, Sergey Senozhatsky wrote:
> Hi Marco,
>
> On (20/07/18 14:10), Marco Elver wrote:
> >
> > It seems this causes a regression observed at least with newline-only
> > printks. I noticed this during -next testing because various debugging
> > tools (K*SAN, lockd
Hi Marco,
On (20/07/18 14:10), Marco Elver wrote:
>
> It seems this causes a regression observed at least with newline-only
> printks. I noticed this during -next testing because various debugging
> tools (K*SAN, lockdep, etc.) use e.g. pr_{err,warn,info}("\n") to format
> reports.
>
> Without w
On Thu, Jul 09, 2020 at 03:29PM +0206, John Ogness wrote:
> Replace the existing ringbuffer usage and implementation with
> lockless ringbuffer usage. Even though the new ringbuffer does not
> require locking, all existing locking is left in place. Therefore,
> this change is purely replacing the u
Replace the existing ringbuffer usage and implementation with
lockless ringbuffer usage. Even though the new ringbuffer does not
require locking, all existing locking is left in place. Therefore,
this change is purely replacing the underlining ringbuffer.
Changes that exist due to the ringbuffer r
13 matches
Mail list logo
