Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console)

[Petr Mladek <pmladek@suse.com>]

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@synopsys.com> 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