On (20/10/08 10:50), Petr Mladek wrote:
> On Wed 2020-10-07 21:30:44, Sergey Senozhatsky wrote:
> > On (20/10/07 09:28), Petr Mladek wrote:
> > >
> > > /*
> > > * Dirty hack to prevent using any console with tty
> > > * binding as a fallback and adding the empty
> > > * name into console_cmdline array.
> > > */
> > > preferred_console = MAX_CMDLINECONSOLES;
> >
> > Let me dump my findings so far. I still don't understand what exactly
> > crashes the laptop (blank screen is not very helpful).
> >
> > So, things start with the "preferred_console = -1". In console_setup()
> > we call __add_preferred_console(). Since we have no consoles, the
> > name matching loop is not executed, and console selection counter remains
> > at 0. After the loop, despite the fact that we don't have the console
> > (`name' is empty), we still set `preferred_console', to 0.
>
> Heh, we actually add the console.
To the console drovers list? I don't think so. At least on my laptop
what I have is as follows:
/* See if this console matches one we selected on the command line */
err = try_enable_new_console(newcon, true);
/* If not, try to match against the platform default(s) */
if (err == -ENOENT)
err = try_enable_new_console(newcon, false);
/* printk() messages are not printed to the Braille console. */
if (err || newcon->flags & CON_BRL)
return;
We hit this error return. Because both try_enable_new_console() return
-ENOENT. So this is never executed
...
console_lock();
if ((newcon->flags & CON_CONSDEV) || console_drivers == NULL) {
newcon->next = console_drivers;
console_drivers = newcon;
if (newcon->next)
newcon->next->flags &= ~CON_CONSDEV;
/* Ensure this flag is always set for the head of the list */
newcon->flags |= CON_CONSDEV;
} else {
newcon->next = console_drivers->next;
console_drivers->next = newcon;
}
...
The console driver list is 0x00.
> I wonder if you see the problem solved by the commit 2d3145f8d2809592ef8
> ("early init: fix error handling when opening /dev/console").
/dev/console does exist. What does not exist is console driver, because
console drivers list is NULL. So the failure here is not filp_open()
per se, but tty_lookup_driver()->console_device(), which returns NULL.
As far as I'm concerned.
> I am also curious about the commit 74f1a299107b9e1a56 "Revert "fs:
> remove ksys_dup()"". I wonder why it was safe to call ksys_dup(0);
> even though the previous ksys_open() failed.
I'm quite sure ksys_dup(0) fails, in fact. I guess the issue here boils
down to user-space that does modprobe/fsck/mount and what kind of things
it attempts to do with standard file descriptors 0/1/2.
> PS: I am quite busy with something else this week.
Sure, no prob. Thanks.
-ss
