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