Subject: Re: Regression in 4.9-rc1 for PPC32 - bisected to commit 05fd007e4629
To: LKML <linux-kernel@vger.kernel.org>,
        Paul Burton <paul.burton@imgtec.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thorsten Leemhuis <regressions@leemhuis.info>
References: <2ccf74f5-5fa2-2f47-ade1-69addc79c40b@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Message-ID: <3c739d34-3006-794f-8cf7-64a9a1287702@lwfinger.net>
Date: Sat, 22 Oct 2016 12:36:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <2ccf74f5-5fa2-2f47-ade1-69addc79c40b@lwfinger.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2831
Lines: 74

On 10/20/2016 12:55 AM, Larry Finger wrote:
> Kernel 4.9-rc1 fails to boot on my PowerBook G4 Aluminum (32-bit PowerPC) with
> the following splat:
>
> Kernel Panic - not synching: Attempted to kill init: exitcode = 0x00000200
>
> Call trace:
>
> dump_stack+0x24/0x34 (unreliable)
> panic+0x110/0x2ac
> do_exit+0x464/0x834
> do_group_exit+0x84/0xac
> __wake_up_parent+0x0/0x34
> ret_from_syscall+0x0/0x40
>
> As the panic happens very early, I was not able to capture the output, thus the
> above was entered by hand.
>
> The problem was bisected to commit 05fd007e4629 ("console: don't prefer first
> registered if DT specifies stdout-path"). Examining that patch and testing the
> various hunks, I found that the system booted fine when I eliminated the hunk at
>
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2077,6 +2077,8 @@ 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)
>
> Similarly, it would boot if I eliminated the hunk at
>
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2647,7 +2658,7 @@ void register_console(struct console *newcon)
>          *      didn't select a console we take the first one
>          *      that registers here.
>          */
> -       if (preferred_console < 0) {
> +       if (preferred_console < 0 && !of_specified_console) {
>                 if (newcon->index < 0)
>                         newcon->index = 0;
>                 if (newcon->setup == NULL ||
>
> The problem happens when of_specified_console is true, and the code following
> the modified if statement above is not executed. In my .config, CONFIG_OF=y.
>
> As always, I will be happy to test any fixes.

I have done some testing regarding this regression. I hope that this will help 
in finding a fix for the problem.

When I remove the test of "of_specified_console" in the if statement above, 
nothing changes in the first time through register_console(). At this point, 
newcon->device is NULL, and "bootconsole [udbg0] selected" is logged sometime 
after that call. The second time register_console() is called, newcon->device is 
c0323b48, and the log contains

console [tty0] enabled
console [udbg0] disabled

At this point newcon->device has been changed to c0329960. Routine 
register_console() is called 5 more times with a netcon->device value of 
c032e7ec, but the console is not changed again.

If the code is never allowed to execute the if block in question, the 
bootconsole [udbg0] is never replaced, which leads to the kernel panic.

Larry