| Message ID | 20161018091852.14776-1-paul.burton@imgtec.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Okt 18 2016, Paul Burton <paul.burton@imgtec.com> wrote: > If a device tree specified a preferred device for kernel console output > via the stdout-path or linux,stdout-path chosen node properties there's > no guarantee that it will have specified a device for which we have a > driver. It may also be the case that we do have a driver but it doesn't > call of_console_check() to register as a preferred console (eg. offb > driver as used on powermac systems). In these cases try to ensure that > we provide some console output by enabling the first console in the > console_drivers list. > > As I don't have access to an affected system this has only been build > tested - testing would be most appreciated. Unfortunately that doesn't work. The initial console still cannot be opened. Andreas.
Any news? Andreas.
Andreas Schwab <schwab@linux-m68k.org> writes:
> Any news?
We discovered it also breaks VGA on qemu, which presumably is not the
type of news you were hoping for.
To reproduce you just need to build a ppc64le kernel:
$ apt-get install gcc-powerpc64le-linux-gnu
$ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- pseries_le_defconfig
$ make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu-
And then run qemu:
$ qemu-system-ppc64 -M pseries -m 1G -kernel vmlinux
Which will display the Tux logo but then nothing else and then reboot
after 10 seconds or so.
If you revert 05fd007e4629 on top of rc3 it boots fine.
Paul I tried your "console: use first console if stdout-path device
doesn't appear" patch, but it didn't help. I'll try and work out why,
but it's a bit hard with no output :)
If we can't come up with a fix soon I'm inclined to ask for a revert.
cheers
Hi Michael et al, On Monday, 31 October 2016 16:28:59 GMT Michael Ellerman wrote: > Andreas Schwab <schwab@linux-m68k.org> writes: > > Any news? > > We discovered it also breaks VGA on qemu, which presumably is not the > type of news you were hoping for. On the contrary, that's wonderful news - I can test that! Huzzah for brokenness! Thanks for your steps to reproduce the issue. Could you try my v2 patch? It works for me in QEMU, at least as far as seeing the kernel console output for a panic due to not having a rootfs. Hopefully it works for you (& Andreas & Larry) too: https://patchwork.kernel.org/patch/9405415/ Thanks, Paul
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index d5e3973..7091e2f 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -2835,10 +2835,45 @@ EXPORT_SYMBOL(unregister_console); * intersects with the init section. Note that code exists elsewhere to get * rid of the boot console as soon as the proper console shows up, so there * won't be side-effects from postponing the removal. + * + * Additionally we may be using a device tree which specifies valid + * stdout-path referencing a device for which we don't have a driver, or for + * which we have a driver that doesn't register itself as preferred console + * using of_console_check(). In these cases we attempt here to enable the + * first registered console. */ static int __init printk_late_init(void) { - struct console *con; + struct console *con, *enabled; + + if (of_specified_console) { + console_lock(); + + /* Find the enabled console, if there is one */ + enabled = NULL; + for_each_console(con) { + if (!(con->flags & CON_ENABLED)) + continue; + + enabled = con; + break; + } + + /* Enable the first console if none were already enabled */ + con = console_drivers; + if (!enabled && con) { + if (con->index < 0) + con->index = 0; + if (con->setup == NULL || + con->setup(con, NULL) == 0) { + con->flags |= CON_ENABLED; + if (con->device) + con->flags |= CON_CONSDEV; + } + } + + console_unlock(); + } for_each_console(con) { if (!keep_bootcon && con->flags & CON_BOOT) {
If a device tree specified a preferred device for kernel console output via the stdout-path or linux,stdout-path chosen node properties there's no guarantee that it will have specified a device for which we have a driver. It may also be the case that we do have a driver but it doesn't call of_console_check() to register as a preferred console (eg. offb driver as used on powermac systems). In these cases try to ensure that we provide some console output by enabling the first console in the console_drivers list. As I don't have access to an affected system this has only been build tested - testing would be most appreciated. Signed-off-by: Paul Burton <paul.burton@imgtec.com> Fixes: 05fd007e4629 ("console: don't prefer first registered if DT specifies stdout-path") Reported-by: Andreas Schwab <schwab@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Borislav Petkov <bp@suse.de> Cc: Tejun Heo <tj@kernel.org> Cc: linux-kernel@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org --- A potential alternative to this might be to have the affected offb driver call of_check_console(), and perhaps that should happen anyway, but doing so seems non-trivial since the offb driver doesn't know the index of the framebuffer console device it may be about to register & the fbdev core doesn't know the associated device tree node. This also wouldn't catch the case of us not having a driver for the device specified by stdout-path, so this fallback seems worthwhile anyway. --- kernel/printk/printk.c | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-)