Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1637969 > unrolled thread

Re: [PATCH v9 3/3] printk: fix double printing with earlycon

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v9 3/3] printk: fix double printing with earlycon Sabrina Dubroca <sd@queasysnail.net> - 2017-05-09 10:30 +0200
    Re: [PATCH v9 3/3] printk: fix double printing with earlycon Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-05-11 10:30 +0200
      Re: [PATCH v9 3/3] printk: fix double printing with earlycon Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-05-11 10:50 +0200
        Re: [PATCH v9 3/3] printk: fix double printing with earlycon Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2017-05-11 13:40 +0200

#1637969 — Re: [PATCH v9 3/3] printk: fix double printing with earlycon

Hi Aleksey,

2017-04-05, 23:20:00 +0300, Aleksey Makarov wrote:
> If a console was specified by ACPI SPCR table _and_ command line
> parameters like "console=ttyAMA0" _and_ "earlycon" were specified,
> then log messages appear twice.
> 
> The root cause is that the code traverses the list of specified
> consoles (the `console_cmdline` array) and stops at the first match.
> But it may happen that the same console is referred by the elements
> of this array twice:
> 
> 	pl011,mmio,0x87e024000000,115200 -- from SPCR
> 	ttyAMA0 -- from command line
> 
> but in this case `preferred_console` points to the second entry and
> the flag CON_CONSDEV is not set, so bootconsole is not deregistered.
> 
> To fix that, introduce an invariant "The last non-braille console
> is always the preferred one" on the entries of the console_cmdline
> array.  Then traverse it in reverse order to be sure that if
> the console is preferred then it will be the first matching entry.
> Introduce variable console_cmdline_cnt that keeps the number
> of elements of the console_cmdline array (Petr Mladek).  It helps
> to get rid of the loop that searches for the end of this array.

That's caused a change of behavior in my qemu setup, with this cmdline

    root=/dev/sda1 console=ttyS1 console=ttyS0

Before, the kernel logs appeared on ttyS1, and I logged in with ttyS0
(with my setup, ttyS1 is a file and ttyS0 is unix socket). Now, the
kernel logs go to ttyS0. I need to swap the two console= parameters to
restore behavior.

There might be some other problem (in qemu?) though, because adding
console=tty0 anywhere on that cmdline makes the logs appear on both
tty0 and one ttyS* (but only one of them, and the ordering of the
ttyS* matters).


Thanks,

-- 
Sabrina

[toc] | [next] | [standalone]

#1639240

On (05/09/17 10:29), Sabrina Dubroca wrote:
[..]
> That's caused a change of behavior in my qemu setup, with this cmdline
> 
>     root=/dev/sda1 console=ttyS1 console=ttyS0
> 
> Before, the kernel logs appeared on ttyS1, and I logged in with ttyS0
> (with my setup, ttyS1 is a file and ttyS0 is unix socket). Now, the
> kernel logs go to ttyS0. I need to swap the two console= parameters to
> restore behavior.
> 
> There might be some other problem (in qemu?) though, because adding
> console=tty0 anywhere on that cmdline makes the logs appear on both
> tty0 and one ttyS* (but only one of them, and the ordering of the
> ttyS* matters).

thanks for the report.

so we have ttyS1 first and ttyS0 last.
after commit in question, register_console() iterates console_cmdline
in reverse order so we see ttyS0 first, then we hit `if (newcon->index < 0)'
condition, set newcon to ttyS0, because we iterate in reverse order now, and
break out. so we enable ttyS0, instead of ttyS1.

previously, we iterated console_cmdline from index 0 and saw ttyS1 first.
so the same `if (newcon->index < 0)' condition would set newcone to ttyS1,
and, thus, we would enable ttyS1, not ttyS0.

	-ss

[toc] | [prev] | [next] | [standalone]

#1639252

On (05/11/17 17:24), Sergey Senozhatsky wrote:
> On (05/09/17 10:29), Sabrina Dubroca wrote:
> [..]
> > That's caused a change of behavior in my qemu setup, with this cmdline
> > 
> >     root=/dev/sda1 console=ttyS1 console=ttyS0
> > 
> > Before, the kernel logs appeared on ttyS1, and I logged in with ttyS0
> > (with my setup, ttyS1 is a file and ttyS0 is unix socket). Now, the
> > kernel logs go to ttyS0. I need to swap the two console= parameters to
> > restore behavior.
> > 
> > There might be some other problem (in qemu?) though, because adding
> > console=tty0 anywhere on that cmdline makes the logs appear on both
> > tty0 and one ttyS* (but only one of them, and the ordering of the
> > ttyS* matters).
> 
> thanks for the report.
> 
> so we have ttyS1 first and ttyS0 last.
> after commit in question, register_console() iterates console_cmdline
> in reverse order so we see ttyS0 first, then we hit `if (newcon->index < 0)'
> condition, set newcon to ttyS0, because we iterate in reverse order now, and
> break out. so we enable ttyS0, instead of ttyS1.
> 
> previously, we iterated console_cmdline from index 0 and saw ttyS1 first.
> so the same `if (newcon->index < 0)' condition would set newcone to ttyS1,
> and, thus, we would enable ttyS1, not ttyS0.

Alexey,
can we have preferred console at offset 0 (not at console_cmdline_cnt - 1)
and restore the previous register_console() iteration order?

	-ss

[toc] | [prev] | [next] | [standalone]

#1639320

On (05/11/17 17:41), Sergey Senozhatsky wrote:
[..]
> Alexey,
> can we have preferred console at offset 0 (not at console_cmdline_cnt - 1)
> and restore the previous register_console() iteration order?

btw, what if someone has configured the system as
console=   non-braille non-braille braille non-braille?
"The last non-braille console is always the preferred one"
is not true in this case.

	-ss

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web