On Thu 2021-01-07 21:18:20, Vineet Gupta wrote: > On 1/7/21 7:48 PM, Sergey Senozhatsky wrote: > > On (21/01/07 09:58), Vineet Gupta wrote: > > > On 1/7/21 9:04 AM, Petr Mladek wrote: > > > > On Thu 2021-01-07 08:43:16, Vineet Gupta wrote: > > > > > Hi John, > > > > > > > > > > On 1/7/21 1:02 AM, John Ogness wrote: > > > > > > Hi Vineet, > > > > > > > > > > > > On 2021-01-06, Vineet Gupta <vgupta@xxxxxxxxxxxx> wrote: > > > > > > > This breaks ARC booting (no output on console). > > > > > > > > > > > > Could you provide the kernel boot arguments that you use? This series is > > > > > > partly about addressing users that have used boot arguments that are > > > > > > technically incorrect (even if had worked). Seeing the boot arguments of > > > > > > users that are not experiencing problems may help to reveal some of the > > > > > > unusual console usages until now. > > > > > > > > > > > > > > > Kernel command line: earlycon=uart8250,mmio32,0xf0005000,115200n8 > > > > > console=ttyS0,115200n8 debug print-fatal-signals=1 > > > > > > > > This is strange, the problematic patch should use ttynull > > > > only as a fallback. It should not be used when a particular console > > > > is defined on the command line. > > > > > > What happens in my case is console_on_rootfs() doesn't find /dev/console and > > > switching to ttynull. /dev is not present because devtmpfs doesn't automount > > > for initramfs. I see. I did not though about a possibility that /dev/console could not be opened from other reasons. > > I wonder if we'll move the nulltty fallback logic into printk code [1] > > will it fix the problem? > > > > [1] https://lore.kernel.org/lkml/X6x%2FAxD1qanC6evJ@jagdpanzerIV.localdomain/ > > Your reasoning in the post above makes total sense. > > I tired the patch: adding register_ttynull_console() call in > console_device(), removing from console_on_rootfs() band that works too. IMHO, this worked because you removed the change in console_on_rootfs(). I guess that the change in console_device() did not make any difference. It was likely not called because filp_open("/dev/console", O_RDWR, 0) failed earlier because /dev/ did not exists. Anyway, the proposed change in console_device() has some more problems that I realized this week: + It does not check whether console_drivers really contains any console with tty binding. + register_ttynull_console() calls add_preferred_console(ttynull_console.name, 0, NULL). The ttynull console stays preferred even when any better console gets registered later. As a result, it would stay associated with /dev/console. The right solution would be to enable ttynull console and do _not_ modify the list of preferred consoles. And it makes sense to add the console only there is no console with tty binding at the moment. I still have to think whether console_device() is a better or worse location for adding tyynull as a fallback. Anyway, it has to wait. The proper solution can't be done easily with the existing register_console() code. We need to clean it up first. Best Regards, Petr
