On Tue 2021-01-05 17:17:08, Petr Mladek wrote:
On Tue 2020-12-22 09:43:48, David Gow wrote:
On Tue, Dec 22, 2020 at 4:02 AM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Mon, Dec 21, 2020 at 09:40:08PM +0200, Andy Shevchenko wrote:
+Cc people from culprit commit
Guys, revert helps. I am open to test any solution you may propose, thanks!
...
# first bad commit: [757055ae8dedf5333af17b3b5b4b70ba9bc9da4e] init/console: Use ttynull as a fallback when there is no console
--
+CC linux-um
There appear to be two problems here:
- UML now no longer has console output by default (which KUnit needs
to get results)
This can be worked around for KUnit by passing console=tty to the kernel. I don't think this is a "correct" fix
It is rather a workaround. ttynull was supposed to be an ultimate fallback to provide a "valid" stdin, stdout, and stderr for the init process. ttyX still should be used by default when there is no console defined on the command line.
So the question is why ttyX was not registered with this patch.
I see the problem even when I revert the commit 757055ae8dedf5333af ("init/console: Use ttynull as a fallback when there is no console") and enable the ttynull driver as built in:
CONFIG_NULL_TTY=yBy other words, the problem existed even before. The commit only made it visible by default.
I am still trying to understand arch/um and kunit code. I wonder if it is somehow related to stdiocons implemented in arch/um/drivers/stdio_console.c.
The following change solved the problem for me as well. It causes that ttynull is initialized after stdiocons console.
diff --git a/drivers/tty/ttynull.c b/drivers/tty/ttynull.c index eced70ec54e1..602af4d30bd4 100644 --- a/drivers/tty/ttynull.c +++ b/drivers/tty/ttynull.c @@ -121,7 +121,6 @@ static void __exit ttynull_exit(void) tty_port_destroy(&ttynull_port); }
-module_init(ttynull_init); -module_exit(ttynull_exit); +late_initcall_sync(ttynull_init);
MODULE_LICENSE("GPL v2");
But I am not completely sure that it is the right solution.
It is strange. Console should get registered only when it was added by add_preferred_console(). It means that ttynull_init() should not register by default.
Some clue might be in stderr_console. It has to be explicitly unregistered to avoid staying as the default console, see unregister_stderr() in arch/um/drivers/stderr_console.c
I am going to dig more into it.
Best Regards, Petr