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

Groups > linux.kernel > #1515165 > unrolled thread

[REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards

Back to article view | Back to linux.kernel

Contents

  [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards Hans de Goede <hdegoede@redhat.com> - 2016-11-04 13:20 +0100
    [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path" Hans de Goede <hdegoede@redhat.com> - 2016-11-04 13:20 +0100
      Re: [PATCH] Revert  "console: don't prefer first registered if DT specifies stdout-path" Andrew Morton <akpm@linux-foundation.org> - 2016-11-04 20:40 +0100
      Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path" Michael Ellerman <mpe@ellerman.id.au> - 2016-11-08 01:50 +0100
        Re: [PATCH] Revert "console: don't prefer first registered if DT  specifies stdout-path" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-11-08 08:10 +0100
          Re: [PATCH] Revert "console: don't prefer first registered if DT  specifies stdout-path" Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-11-10 15:20 +0100
    Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards Paul Burton <paul.burton@imgtec.com> - 2016-11-04 13:40 +0100
      Re: [REGRESSION] "console: don't prefer first registered if DT  specifies stdout-path" breaks console on video outputs of various ARM boards Hans de Goede <hdegoede@redhat.com> - 2016-11-04 14:30 +0100
        Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards Paul Burton <paul.burton@imgtec.com> - 2016-11-05 13:10 +0100
          Re: [REGRESSION] "console: don't prefer first registered if DT  specifies stdout-path" breaks console on video outputs of various ARM boards Hans de Goede <hdegoede@redhat.com> - 2016-11-06 12:00 +0100
            Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards Paul Burton <paul.burton@imgtec.com> - 2016-11-07 18:20 +0100
              Re: [REGRESSION] "console: don't prefer first registered if DT  specifies stdout-path" breaks console on video outputs of various ARM boards Hans de Goede <hdegoede@redhat.com> - 2016-11-08 10:20 +0100
        Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards Paul Burton <paul.burton@imgtec.com> - 2016-11-05 13:20 +0100
    Re: [REGRESSION] "console: don't prefer first registered if DT  specifies stdout-path" breaks console on video outputs of various ARM boards Thorsten Leemhuis <regressions@leemhuis.info> - 2016-11-06 13:20 +0100

#1515165 — [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards

Hi All,

While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
I noticed that after u-boot the LCD display stayed black. It turns out
that there was an issue which caused X to never get up, and all kernel
(and other startup) messages prior to that only went to ttyS0 which
consists of 2 tiny testpads on the PCB with this tablet.

The same issue will also happen on any ARM boards which have a HDMI or
composite video output and which use a stdout-path pointing to their
serial console. I think this will e.g. also impact the Raspberry Pi,
I know for certain that this will impact the 99 different Allwinnner
boards currently supported by mainline u-boot + the mainline kernel.

This is a behavior changes from previous kernels and I consider this
a regression. Thus I propose to revert the commit in question, for more
info here is a partial copy of the commit message of the proposed revert:

The reverted commit changes existing behavior on which many ARM boards
rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
both a video output and a serial console. Depending on whether the user
is using the device as a more regular computer; or as a headless device
we need to have the console on either one or the other.

Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64
tty0                 -WU (E  p  )    4:1

Where as after the reverted commit, it looks like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64

This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.

Regards,

Hans

[toc] | [next] | [standalone]

#1515166 — [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

This reverts commit 05fd007e4629 ("console: don't prefer first registered
if DT specifies stdout-path").

The reverted commit changes existing behavior on which many ARM boards
rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
both a video output and a serial console. Depending on whether the user
is using the device as a more regular computer; or as a headless device
we need to have the console on either one or the other.

Many users rely on the kernel behavior of the console being present on
both outputs, before the reverted commit the console setup with no
console= kernel arguments on an ARM board which sets stdout-path in dt
would look like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64
tty0                 -WU (E  p  )    4:1

Where as after the reverted commit, it looks like this:

[root@localhost ~]# cat /proc/consoles
ttyS0                -W- (EC p a)    4:64

This commit reverts commit 05fd007e4629 ("console: don't prefer first
registered if DT specifies stdout-path") restoring the original behavior.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/of/base.c       |  2 --
 include/linux/console.h |  6 ------
 kernel/printk/printk.c  | 13 +------------
 3 files changed, 1 insertion(+), 20 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index d687e6d..a0bccb5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2077,8 +2077,6 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 align))
 			name = of_get_property(of_aliases, "stdout", NULL);
 		if (name)
 			of_stdout = of_find_node_opts_by_path(name, &of_stdout_options);
-		if (of_stdout)
-			console_set_by_of();
 	}
 
 	if (!of_aliases)
diff --git a/include/linux/console.h b/include/linux/console.h
index 3672809..d530c46 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -173,12 +173,6 @@ static inline void console_sysfs_notify(void)
 #endif
 extern bool console_suspend_enabled;
 
-#ifdef CONFIG_OF
-extern void console_set_by_of(void);
-#else
-static inline void console_set_by_of(void) {}
-#endif
-
 /* Suspend and resume console messages over PM events */
 extern void suspend_console(void);
 extern void resume_console(void);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index de08fc9..5028f4f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -253,17 +253,6 @@ static int preferred_console = -1;
 int console_set_on_cmdline;
 EXPORT_SYMBOL(console_set_on_cmdline);
 
-#ifdef CONFIG_OF
-static bool of_specified_console;
-
-void console_set_by_of(void)
-{
-	of_specified_console = true;
-}
-#else
-# define of_specified_console false
-#endif
-
 /* Flag: console code may call schedule() */
 static int console_may_schedule;
 
@@ -2657,7 +2646,7 @@ void register_console(struct console *newcon)
 	 *	didn't select a console we take the first one
 	 *	that registers here.
 	 */
-	if (preferred_console < 0 && !of_specified_console) {
+	if (preferred_console < 0) {
 		if (newcon->index < 0)
 			newcon->index = 0;
 		if (newcon->setup == NULL ||
-- 
2.9.3

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

#1515374 — Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

On Fri,  4 Nov 2016 13:11:35 +0100 Hans de Goede <hdegoede@redhat.com> wrote:

> This reverts commit 05fd007e4629 ("console: don't prefer first registered
> if DT specifies stdout-path").
> 
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> both a video output and a serial console. Depending on whether the user
> is using the device as a more regular computer; or as a headless device
> we need to have the console on either one or the other.
> 
> Many users rely on the kernel behavior of the console being present on
> both outputs, before the reverted commit the console setup with no
> console= kernel arguments on an ARM board which sets stdout-path in dt
> would look like this:
> 
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> tty0                 -WU (E  p  )    4:1
> 
> Where as after the reverted commit, it looks like this:
> 
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> 
> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") restoring the original behavior.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

I've added cc:stable@vger.kernel.org to my copy of this.

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

#1516706 — Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

Hans de Goede <hdegoede@redhat.com> writes:

> This reverts commit 05fd007e4629 ("console: don't prefer first registered
> if DT specifies stdout-path").
>
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> both a video output and a serial console. Depending on whether the user
> is using the device as a more regular computer; or as a headless device
> we need to have the console on either one or the other.
>
> Many users rely on the kernel behavior of the console being present on
> both outputs, before the reverted commit the console setup with no
> console= kernel arguments on an ARM board which sets stdout-path in dt
> would look like this:
>
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> tty0                 -WU (E  p  )    4:1
>
> Where as after the reverted commit, it looks like this:
>
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
>
> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") restoring the original behavior.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This is also breaking various powerpc systems.

Linus can you please merge this revert for 4.9 ?

cheers

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

#1516887 — Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

On Tue, Nov 08, 2016 at 11:46:35AM +1100, Michael Ellerman wrote:
> Hans de Goede <hdegoede@redhat.com> writes:
> 
> > This reverts commit 05fd007e4629 ("console: don't prefer first registered
> > if DT specifies stdout-path").
> >
> > The reverted commit changes existing behavior on which many ARM boards
> > rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> > both a video output and a serial console. Depending on whether the user
> > is using the device as a more regular computer; or as a headless device
> > we need to have the console on either one or the other.
> >
> > Many users rely on the kernel behavior of the console being present on
> > both outputs, before the reverted commit the console setup with no
> > console= kernel arguments on an ARM board which sets stdout-path in dt
> > would look like this:
> >
> > [root@localhost ~]# cat /proc/consoles
> > ttyS0                -W- (EC p a)    4:64
> > tty0                 -WU (E  p  )    4:1
> >
> > Where as after the reverted commit, it looks like this:
> >
> > [root@localhost ~]# cat /proc/consoles
> > ttyS0                -W- (EC p a)    4:64
> >
> > This commit reverts commit 05fd007e4629 ("console: don't prefer first
> > registered if DT specifies stdout-path") restoring the original behavior.
> >
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> This is also breaking various powerpc systems.
> 
> Linus can you please merge this revert for 4.9 ?

I'll queue it up with other tty changes for 4.9-final.

thanks,

greg k-h

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

#1519001 — Re: [PATCH] Revert "console: don't prefer first registered if DT specifies stdout-path"

On Tue, Nov 08, 2016 at 08:00:32AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 08, 2016 at 11:46:35AM +1100, Michael Ellerman wrote:
> > Hans de Goede <hdegoede@redhat.com> writes:
> > 
> > > This reverts commit 05fd007e4629 ("console: don't prefer first registered
> > > if DT specifies stdout-path").
> > >
> > > The reverted commit changes existing behavior on which many ARM boards
> > > rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> > > both a video output and a serial console. Depending on whether the user
> > > is using the device as a more regular computer; or as a headless device
> > > we need to have the console on either one or the other.
> > >
> > > Many users rely on the kernel behavior of the console being present on
> > > both outputs, before the reverted commit the console setup with no
> > > console= kernel arguments on an ARM board which sets stdout-path in dt
> > > would look like this:
> > >
> > > [root@localhost ~]# cat /proc/consoles
> > > ttyS0                -W- (EC p a)    4:64
> > > tty0                 -WU (E  p  )    4:1
> > >
> > > Where as after the reverted commit, it looks like this:
> > >
> > > [root@localhost ~]# cat /proc/consoles
> > > ttyS0                -W- (EC p a)    4:64
> > >
> > > This commit reverts commit 05fd007e4629 ("console: don't prefer first
> > > registered if DT specifies stdout-path") restoring the original behavior.
> > >
> > > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> > 
> > This is also breaking various powerpc systems.
> > 
> > Linus can you please merge this revert for 4.9 ?
> 
> I'll queue it up with other tty changes for 4.9-final.

Oops, wait, it's going through Andrew's tree, nevermind...

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

#1515177

[Multipart message — attachments visible in raw view] — view raw

Hi Hans,

On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
> Hi All,
> 
> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> I noticed that after u-boot the LCD display stayed black. It turns out
> that there was an issue which caused X to never get up, and all kernel
> (and other startup) messages prior to that only went to ttyS0 which
> consists of 2 tiny testpads on the PCB with this tablet.
> 
> The same issue will also happen on any ARM boards which have a HDMI or
> composite video output and which use a stdout-path pointing to their
> serial console. I think this will e.g. also impact the Raspberry Pi,
> I know for certain that this will impact the 99 different Allwinnner
> boards currently supported by mainline u-boot + the mainline kernel.
> 
> This is a behavior changes from previous kernels and I consider this
> a regression. Thus I propose to revert the commit in question, for more
> info here is a partial copy of the commit message of the proposed revert:
> 
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> both a video output and a serial console. Depending on whether the user
> is using the device as a more regular computer; or as a headless device
> we need to have the console on either one or the other.
> 
> Many users rely on the kernel behavior of the console being present on
> both outputs, before the reverted commit the console setup with no
> console= kernel arguments on an ARM board which sets stdout-path in dt
> would look like this:
> 
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> tty0                 -WU (E  p  )    4:1
> 
> Where as after the reverted commit, it looks like this:
> 
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> 
> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") restoring the original behavior.
> 
> Regards,
> 
> Hans

Ugh... so the devices you're talking about rely upon set stdout-path in their 
device tree but effectively rely upon us ignoring it?

If that's the case then I guess reverting is probably the best option, but it 
does restore us to a position where we honor stdout-path for earlycon & then 
essentially ignore it for the proper kernel console. That seems pretty bust to 
me...

Thanks,
    Paul

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

#1515193 — Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards

Hi,

On 04-11-16 13:30, Paul Burton wrote:
> Hi Hans,
>
> On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
>> Hi All,
>>
>> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
>> I noticed that after u-boot the LCD display stayed black. It turns out
>> that there was an issue which caused X to never get up, and all kernel
>> (and other startup) messages prior to that only went to ttyS0 which
>> consists of 2 tiny testpads on the PCB with this tablet.
>>
>> The same issue will also happen on any ARM boards which have a HDMI or
>> composite video output and which use a stdout-path pointing to their
>> serial console. I think this will e.g. also impact the Raspberry Pi,
>> I know for certain that this will impact the 99 different Allwinnner
>> boards currently supported by mainline u-boot + the mainline kernel.
>>
>> This is a behavior changes from previous kernels and I consider this
>> a regression. Thus I propose to revert the commit in question, for more
>> info here is a partial copy of the commit message of the proposed revert:
>>
>> The reverted commit changes existing behavior on which many ARM boards
>> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
>> both a video output and a serial console. Depending on whether the user
>> is using the device as a more regular computer; or as a headless device
>> we need to have the console on either one or the other.
>>
>> Many users rely on the kernel behavior of the console being present on
>> both outputs, before the reverted commit the console setup with no
>> console= kernel arguments on an ARM board which sets stdout-path in dt
>> would look like this:
>>
>> [root@localhost ~]# cat /proc/consoles
>> ttyS0                -W- (EC p a)    4:64
>> tty0                 -WU (E  p  )    4:1
>>
>> Where as after the reverted commit, it looks like this:
>>
>> [root@localhost ~]# cat /proc/consoles
>> ttyS0                -W- (EC p a)    4:64
>>
>> This commit reverts commit 05fd007e4629 ("console: don't prefer first
>> registered if DT specifies stdout-path") restoring the original behavior.
>>
>> Regards,
>>
>> Hans
>
> Ugh... so the devices you're talking about rely upon set stdout-path in their
> device tree but effectively rely upon us ignoring it?

No they rely on the kernel using stdout-path as an extra console while keeping
tty0 as console, not ignoring it. This how stdout-path has always worked
(at least as long as the Allwinner boards have used it, which has been
  2 - 3 years now).

If you want only the console specified by stdout-path you can get this by
specifying it with console=... on the kernel cmdline.

> If that's the case then I guess reverting is probably the best option, but it
> does restore us to a position where we honor stdout-path for earlycon & then
> essentially ignore it for the proper kernel console. That seems pretty bust to
> me...

We do not ignore it, we use both the tty pointed to by stdout-path and tty0.

Regards,

Hans

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

#1515532

[Multipart message — attachments visible in raw view] — view raw

On Friday, 4 November 2016 14:22:17 GMT Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 13:30, Paul Burton wrote:
> > Hi Hans,
> > 
> > On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
> >> Hi All,
> >> 
> >> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> >> I noticed that after u-boot the LCD display stayed black. It turns out
> >> that there was an issue which caused X to never get up, and all kernel
> >> (and other startup) messages prior to that only went to ttyS0 which
> >> consists of 2 tiny testpads on the PCB with this tablet.
> >> 
> >> The same issue will also happen on any ARM boards which have a HDMI or
> >> composite video output and which use a stdout-path pointing to their
> >> serial console. I think this will e.g. also impact the Raspberry Pi,
> >> I know for certain that this will impact the 99 different Allwinnner
> >> boards currently supported by mainline u-boot + the mainline kernel.
> >> 
> >> This is a behavior changes from previous kernels and I consider this
> >> a regression. Thus I propose to revert the commit in question, for more
> >> info here is a partial copy of the commit message of the proposed revert:
> >> 
> >> The reverted commit changes existing behavior on which many ARM boards
> >> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> >> both a video output and a serial console. Depending on whether the user
> >> is using the device as a more regular computer; or as a headless device
> >> we need to have the console on either one or the other.
> >> 
> >> Many users rely on the kernel behavior of the console being present on
> >> both outputs, before the reverted commit the console setup with no
> >> console= kernel arguments on an ARM board which sets stdout-path in dt
> >> would look like this:
> >> 
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0                -W- (EC p a)    4:64
> >> tty0                 -WU (E  p  )    4:1
> >> 
> >> Where as after the reverted commit, it looks like this:
> >> 
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0                -W- (EC p a)    4:64
> >> 
> >> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> >> registered if DT specifies stdout-path") restoring the original behavior.
> >> 
> >> Regards,
> >> 
> >> Hans
> > 
> > Ugh... so the devices you're talking about rely upon set stdout-path in
> > their device tree but effectively rely upon us ignoring it?
> 
> No they rely on the kernel using stdout-path as an extra console while
> keeping tty0 as console, not ignoring it. This how stdout-path has always
> worked (at least as long as the Allwinner boards have used it, which has
> been 2 - 3 years now).
> 
> If you want only the console specified by stdout-path you can get this by
> specifying it with console=... on the kernel cmdline.
> 
> > If that's the case then I guess reverting is probably the best option, but
> > it does restore us to a position where we honor stdout-path for earlycon
> > & then essentially ignore it for the proper kernel console. That seems
> > pretty bust to me...
> 
> We do not ignore it, we use both the tty pointed to by stdout-path and tty0.
> 
> Regards,
> 
> Hans

Hi Hans,

Could you walk me though how you're getting that behaviour from the current 
code? I don't see how that would happen besides perhaps if drivers are probed 
in a fortunate order. Is that what you're relying upon?

What I see in my systems, and what 05fd007e4629 ("console: don't prefer first 
registered if DT specifies stdout-path") addressed, is that if there are for 
example 2 UARTs uart0 & uart1 that are probed in that order and stdout-path 
indicates that we should use uart1 we wind up essentially ignoring it because 
the ordering of the relevant calls goes:

  - of_console_check() for uart0
  - add_preferred_console() for uart0
  - register_console() for uart0
  - of_console_check() for uart1
  - add_preferred_console() for uart1
  - register_console() for uart1

Since of_check_console() doesn't get called for uart1 until after uart0 has 
been probed, we don't add an entry for it to the console_cmdline array until 
after register_console() has already decided to enable uart0 because 
preferred_console == -1.

I'm not the only one seeing this oddity either, for example see the discussion 
on this patch:

https://patchwork.kernel.org/patch/9263753/

By simply reverting my patch you restore us to a position where so far as I 
can see we simply do not honor stdout-path for the real kernel console.

Thanks,
    Paul

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

#1515673 — Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards

Hi,

On 05-11-16 11:40, Paul Burton wrote:
> On Friday, 4 November 2016 14:22:17 GMT Hans de Goede wrote:
>> Hi,
>>
>> On 04-11-16 13:30, Paul Burton wrote:
>>> Hi Hans,
>>>
>>> On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
>>>> Hi All,
>>>>
>>>> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
>>>> I noticed that after u-boot the LCD display stayed black. It turns out
>>>> that there was an issue which caused X to never get up, and all kernel
>>>> (and other startup) messages prior to that only went to ttyS0 which
>>>> consists of 2 tiny testpads on the PCB with this tablet.
>>>>
>>>> The same issue will also happen on any ARM boards which have a HDMI or
>>>> composite video output and which use a stdout-path pointing to their
>>>> serial console. I think this will e.g. also impact the Raspberry Pi,
>>>> I know for certain that this will impact the 99 different Allwinnner
>>>> boards currently supported by mainline u-boot + the mainline kernel.
>>>>
>>>> This is a behavior changes from previous kernels and I consider this
>>>> a regression. Thus I propose to revert the commit in question, for more
>>>> info here is a partial copy of the commit message of the proposed revert:
>>>>
>>>> The reverted commit changes existing behavior on which many ARM boards
>>>> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
>>>> both a video output and a serial console. Depending on whether the user
>>>> is using the device as a more regular computer; or as a headless device
>>>> we need to have the console on either one or the other.
>>>>
>>>> Many users rely on the kernel behavior of the console being present on
>>>> both outputs, before the reverted commit the console setup with no
>>>> console= kernel arguments on an ARM board which sets stdout-path in dt
>>>> would look like this:
>>>>
>>>> [root@localhost ~]# cat /proc/consoles
>>>> ttyS0                -W- (EC p a)    4:64
>>>> tty0                 -WU (E  p  )    4:1
>>>>
>>>> Where as after the reverted commit, it looks like this:
>>>>
>>>> [root@localhost ~]# cat /proc/consoles
>>>> ttyS0                -W- (EC p a)    4:64
>>>>
>>>> This commit reverts commit 05fd007e4629 ("console: don't prefer first
>>>> registered if DT specifies stdout-path") restoring the original behavior.
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>
>>> Ugh... so the devices you're talking about rely upon set stdout-path in
>>> their device tree but effectively rely upon us ignoring it?
>>
>> No they rely on the kernel using stdout-path as an extra console while
>> keeping tty0 as console, not ignoring it. This how stdout-path has always
>> worked (at least as long as the Allwinner boards have used it, which has
>> been 2 - 3 years now).
>>
>> If you want only the console specified by stdout-path you can get this by
>> specifying it with console=... on the kernel cmdline.
>>
>>> If that's the case then I guess reverting is probably the best option, but
>>> it does restore us to a position where we honor stdout-path for earlycon
>>> & then essentially ignore it for the proper kernel console. That seems
>>> pretty bust to me...
>>
>> We do not ignore it, we use both the tty pointed to by stdout-path and tty0.
>>
>> Regards,
>>
>> Hans
>
> Hi Hans,
>
> Could you walk me though how you're getting that behaviour from the current
> code? I don't see how that would happen besides perhaps if drivers are probed
> in a fortunate order. Is that what you're relying upon?

I guess so, I never looked carefully at this, it has just always worked
until your patch.

> What I see in my systems, and what 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") addressed, is that if there are for
> example 2 UARTs uart0 & uart1 that are probed in that order and stdout-path
> indicates that we should use uart1 we wind up essentially ignoring it because
> the ordering of the relevant calls goes:
>
>   - of_console_check() for uart0
>   - add_preferred_console() for uart0
>   - register_console() for uart0
>   - of_console_check() for uart1
>   - add_preferred_console() for uart1
>   - register_console() for uart1
>
> Since of_check_console() doesn't get called for uart1 until after uart0 has
> been probed, we don't add an entry for it to the console_cmdline array until
> after register_console() has already decided to enable uart0 because
> preferred_console == -1.
>
> I'm not the only one seeing this oddity either, for example see the discussion
> on this patch:
>
> https://patchwork.kernel.org/patch/9263753/
>
> By simply reverting my patch you restore us to a position where so far as I
> can see we simply do not honor stdout-path for the real kernel console.

As said before, we do still honor it, but in your probe example we also get
a (second) serial console on uart0, where as you only want one on uart1.

So I see a few possible solutions here:

1) Do a new version of your patch which changes the  "&& !of_specified_console"
    check to "&& (newcon == tty0 || !of_specified_console)", then we would still
    always register tty0 (as long as it gets registered first, just like now) and
    we would not register uart0 in your above example, note the "newcon == tty0"
    check in my example is pseudo-code. I would be happy to try out such a patch

2) Add a new dt property to enable the new behavior you seek

I'm myself tending towards 1 as a better solution: treat tty0 special, because
some existing setups rely on it always being registered as a console even if
stdout-path is specified and otherwise always honor stdout-path.

Regards,

Hans

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

#1516348

[Multipart message — attachments visible in raw view] — view raw

Hi Hans,

On Sunday, 6 November 2016 11:54:35 GMT Hans de Goede wrote:
> > What I see in my systems, and what 05fd007e4629 ("console: don't prefer
> > first registered if DT specifies stdout-path") addressed, is that if
> > there are for example 2 UARTs uart0 & uart1 that are probed in that order
> > and stdout-path indicates that we should use uart1 we wind up essentially
> > ignoring it because> 
> > the ordering of the relevant calls goes:
> >   - of_console_check() for uart0
> >   - add_preferred_console() for uart0
> >   - register_console() for uart0
> >   - of_console_check() for uart1
> >   - add_preferred_console() for uart1
> >   - register_console() for uart1
> > 
> > Since of_check_console() doesn't get called for uart1 until after uart0
> > has
> > been probed, we don't add an entry for it to the console_cmdline array
> > until after register_console() has already decided to enable uart0
> > because preferred_console == -1.
> > 
> > I'm not the only one seeing this oddity either, for example see the
> > discussion on this patch:
> > 
> > https://patchwork.kernel.org/patch/9263753/
> > 
> > By simply reverting my patch you restore us to a position where so far as
> > I
> > can see we simply do not honor stdout-path for the real kernel console.
> 
> As said before, we do still honor it, but in your probe example we also get
> a (second) serial console on uart0, where as you only want one on uart1.

...but don't we only support one console per type of device? That's what 
Documentation/serial-console.txt says anyway, which means having a console on 
both uart0 & uart1 does not work. I could live with having console output on 
an extra UART, but that's not what I was seeing when I wrote this patch.

> So I see a few possible solutions here:
> 
> 1) Do a new version of your patch which changes the  "&&
> !of_specified_console" check to "&& (newcon == tty0 ||
> !of_specified_console)", then we would still always register tty0 (as long
> as it gets registered first, just like now) and we would not register uart0
> in your above example, note the "newcon == tty0" check in my example is
> pseudo-code. I would be happy to try out such a patch
> 
> 2) Add a new dt property to enable the new behavior you seek
> 
> I'm myself tending towards 1 as a better solution: treat tty0 special,
> because some existing setups rely on it always being registered as a
> console even if stdout-path is specified and otherwise always honor
> stdout-path.
> 
> Regards,
> 
> Hans

That does feel a little hack-ish to me though... I don't like the reliance on 
probe ordering, nor special casing tty0 in general.

In any case I don't think I have the time to unpick all this at the moment, so 
I suggest we go ahead with your revert for now & I'll revisit the system I was 
working on when I find the time.

Thanks,
    Paul

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

#1516980 — Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards

Hi,

On 07-11-16 18:16, Paul Burton wrote:
> Hi Hans,
>
> On Sunday, 6 November 2016 11:54:35 GMT Hans de Goede wrote:
>>> What I see in my systems, and what 05fd007e4629 ("console: don't prefer
>>> first registered if DT specifies stdout-path") addressed, is that if
>>> there are for example 2 UARTs uart0 & uart1 that are probed in that order
>>> and stdout-path indicates that we should use uart1 we wind up essentially
>>> ignoring it because>
>>> the ordering of the relevant calls goes:
>>>   - of_console_check() for uart0
>>>   - add_preferred_console() for uart0
>>>   - register_console() for uart0
>>>   - of_console_check() for uart1
>>>   - add_preferred_console() for uart1
>>>   - register_console() for uart1
>>>
>>> Since of_check_console() doesn't get called for uart1 until after uart0
>>> has
>>> been probed, we don't add an entry for it to the console_cmdline array
>>> until after register_console() has already decided to enable uart0
>>> because preferred_console == -1.
>>>
>>> I'm not the only one seeing this oddity either, for example see the
>>> discussion on this patch:
>>>
>>> https://patchwork.kernel.org/patch/9263753/
>>>
>>> By simply reverting my patch you restore us to a position where so far as
>>> I
>>> can see we simply do not honor stdout-path for the real kernel console.
>>
>> As said before, we do still honor it, but in your probe example we also get
>> a (second) serial console on uart0, where as you only want one on uart1.
>
> ...but don't we only support one console per type of device? That's what
> Documentation/serial-console.txt says anyway, which means having a console on
> both uart0 & uart1 does not work. I could live with having console output on
> an extra UART, but that's not what I was seeing when I wrote this patch.

Ah yes, you're probably right about that.

>> So I see a few possible solutions here:
>>
>> 1) Do a new version of your patch which changes the  "&&
>> !of_specified_console" check to "&& (newcon == tty0 ||
>> !of_specified_console)", then we would still always register tty0 (as long
>> as it gets registered first, just like now) and we would not register uart0
>> in your above example, note the "newcon == tty0" check in my example is
>> pseudo-code. I would be happy to try out such a patch
>>
>> 2) Add a new dt property to enable the new behavior you seek
>>
>> I'm myself tending towards 1 as a better solution: treat tty0 special,
>> because some existing setups rely on it always being registered as a
>> console even if stdout-path is specified and otherwise always honor
>> stdout-path.
>>
>> Regards,
>>
>> Hans
>
> That does feel a little hack-ish to me though... I don't like the reliance on
> probe ordering, nor special casing tty0 in general.

Given that we've just got a "me too" reply from the ppc side of things,
it seems that in reality people have been relying on probe ordering here
for a long time now. IMHO tty0 is special, so it does make sense that it
always gets probed first (*) and it does make sense to handle it special.

*) Even though that seems to be more how things work (an implicit thing)
rather then explicit.

> In any case I don't think I have the time to unpick all this at the moment, so
> I suggest we go ahead with your revert for now & I'll revisit the system I was
> working on when I find the time.

Ok.

Regards,

Hans

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

#1515534

[Multipart message — attachments visible in raw view] — view raw

On Friday, 4 November 2016 14:22:17 GMT Hans de Goede wrote:
> Hi,
> 
> On 04-11-16 13:30, Paul Burton wrote:
> > Hi Hans,
> > 
> > On Friday, 4 November 2016 13:11:34 GMT Hans de Goede wrote:
> >> Hi All,
> >> 
> >> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> >> I noticed that after u-boot the LCD display stayed black. It turns out
> >> that there was an issue which caused X to never get up, and all kernel
> >> (and other startup) messages prior to that only went to ttyS0 which
> >> consists of 2 tiny testpads on the PCB with this tablet.
> >> 
> >> The same issue will also happen on any ARM boards which have a HDMI or
> >> composite video output and which use a stdout-path pointing to their
> >> serial console. I think this will e.g. also impact the Raspberry Pi,
> >> I know for certain that this will impact the 99 different Allwinnner
> >> boards currently supported by mainline u-boot + the mainline kernel.
> >> 
> >> This is a behavior changes from previous kernels and I consider this
> >> a regression. Thus I propose to revert the commit in question, for more
> >> info here is a partial copy of the commit message of the proposed revert:
> >> 
> >> The reverted commit changes existing behavior on which many ARM boards
> >> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> >> both a video output and a serial console. Depending on whether the user
> >> is using the device as a more regular computer; or as a headless device
> >> we need to have the console on either one or the other.
> >> 
> >> Many users rely on the kernel behavior of the console being present on
> >> both outputs, before the reverted commit the console setup with no
> >> console= kernel arguments on an ARM board which sets stdout-path in dt
> >> would look like this:
> >> 
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0                -W- (EC p a)    4:64
> >> tty0                 -WU (E  p  )    4:1
> >> 
> >> Where as after the reverted commit, it looks like this:
> >> 
> >> [root@localhost ~]# cat /proc/consoles
> >> ttyS0                -W- (EC p a)    4:64
> >> 
> >> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> >> registered if DT specifies stdout-path") restoring the original behavior.
> >> 
> >> Regards,
> >> 
> >> Hans
> > 
> > Ugh... so the devices you're talking about rely upon set stdout-path in
> > their device tree but effectively rely upon us ignoring it?
> 
> No they rely on the kernel using stdout-path as an extra console while
> keeping tty0 as console, not ignoring it. This how stdout-path has always
> worked (at least as long as the Allwinner boards have used it, which has
> been 2 - 3 years now).
> 
> If you want only the console specified by stdout-path you can get this by
> specifying it with console=... on the kernel cmdline.
> 
> > If that's the case then I guess reverting is probably the best option, but
> > it does restore us to a position where we honor stdout-path for earlycon
> > & then essentially ignore it for the proper kernel console. That seems
> > pretty bust to me...
> 
> We do not ignore it, we use both the tty pointed to by stdout-path and tty0.
> 
> Regards,
> 
> Hans

Hi Hans,

Could you walk me though how you're getting that behaviour from the current 
code? I don't see how that would happen besides perhaps if drivers are probed 
in a fortunate order. Is that what you're relying upon?

What I see in my systems, and what 05fd007e4629 ("console: don't prefer first 
registered if DT specifies stdout-path") addressed, is that if there are for 
example 2 UARTs uart0 & uart1 that are probed in that order and stdout-path 
indicates that we should use uart1 we wind up essentially ignoring it because 
the ordering of the relevant calls goes:

  - of_console_check() for uart0
  - add_preferred_console() for uart0
  - register_console() for uart0
  - of_console_check() for uart1
  - add_preferred_console() for uart1
  - register_console() for uart1

Since of_check_console() doesn't get called for uart1 until after uart0 has 
been probed, we don't add an entry for it to the console_cmdline array until 
after register_console() has already decided to enable uart0 because 
preferred_console == -1.

I'm not the only one seeing this oddity either, for example see the discussion 
on this patch:

https://patchwork.kernel.org/patch/9263753/

By simply reverting my patch you restore us to a position where so far as I 
can see we simply do not honor stdout-path for the real kernel console.

Thanks,
    Paul

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

#1515687 — Re: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards

JFYI: I added below report to the list of regressions for Linux 4.9.
I'll watch this thread for further updates on this issue to document
progress in my weekly reports. Please let me know via
regressions@leemhuis.info in case the discussion moves to a different
place (bugzilla or another mail thread for example).

Current status (afaics): Revert discussed

tia! Ciao, Thorsten

P.S.: Thx for CCing me!

On 04.11.2016 13:11, Hans de Goede wrote:
> Hi All,
> 
> While booting 4.9-rc# for the first time on an Allwinner A33 tablet,
> I noticed that after u-boot the LCD display stayed black. It turns out
> that there was an issue which caused X to never get up, and all kernel
> (and other startup) messages prior to that only went to ttyS0 which
> consists of 2 tiny testpads on the PCB with this tablet.
> 
> The same issue will also happen on any ARM boards which have a HDMI or
> composite video output and which use a stdout-path pointing to their
> serial console. I think this will e.g. also impact the Raspberry Pi,
> I know for certain that this will impact the 99 different Allwinnner
> boards currently supported by mainline u-boot + the mainline kernel.
> 
> This is a behavior changes from previous kernels and I consider this
> a regression. Thus I propose to revert the commit in question, for more
> info here is a partial copy of the commit message of the proposed revert:
> 
> The reverted commit changes existing behavior on which many ARM boards
> rely. Many ARM small-board-computers, like e.g. the Raspberry Pi have
> both a video output and a serial console. Depending on whether the user
> is using the device as a more regular computer; or as a headless device
> we need to have the console on either one or the other.
> 
> Many users rely on the kernel behavior of the console being present on
> both outputs, before the reverted commit the console setup with no
> console= kernel arguments on an ARM board which sets stdout-path in dt
> would look like this:
> 
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> tty0                 -WU (E  p  )    4:1
> 
> Where as after the reverted commit, it looks like this:
> 
> [root@localhost ~]# cat /proc/consoles
> ttyS0                -W- (EC p a)    4:64
> 
> This commit reverts commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path") restoring the original behavior.
> 
> Regards,
> 
> Hans
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web