Messages in this thread | | | Date | Fri, 8 Jan 2021 10:30:33 +0100 | From | Petr Mladek <> | Subject | Re: ARC no console output (was Re: [PATCH 1/2] init/console: Use ttynull as a fallback when there is no console) |
| |
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
| |