Parallelization to improve boot times has been successful enough that race
conditions now exist between the init_post() open of /dev/console and
initialization of the console device. When this occurs, opening /dev/console
fails and any applications inherited for init have no standard in/out/err
devices. This is expected behavior if no console device is available, but
quite unfortunate in the case where the console is just a bit slow waking up.
Some buses, such as USB, offer no guarantees about how long it takes to
discover devices, so there is no reliable way to distinguish between a missing
console and a slow one. The pragmatic approach taken in this patch is to
wait for a while to see if a console shows up, and just go on if it doesn't.
The default delay interval is set to 500 msec (0.5 seconds) based on a sample
size of one device (cp2101) but is a tunable. If the console shows up sooner,
we will continue immediately.
History
v2 Wait for the preferred console rather than any console. Make the
delay interval a tunable.
v1 Initial version
Signed-off-by: David VomLehn <[email protected]>
---
init/Kconfig | 10 ++++++++++
kernel/printk.c | 11 +++++++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 7be4d38..5d5b0fa 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -835,6 +835,16 @@ config PRINTK
very difficult to diagnose system problems, saying N here is
strongly discouraged.
+config PRINTK_CONSOLE_WAIT
+ int "Number of milliseconds to wait for console device"
+ default 500
+ help
+ Some systems use console devices, such as USB serial devices, which
+ may not be present or which may take an unspecified amount of time
+ to be initialized. This setting determines the maximum number of
+ milliseconds the system will wait for a console to be registered.
+ Slow devices may require this value be increased.
+
config BUG
bool "BUG() support" if EMBEDDED
default y
diff --git a/kernel/printk.c b/kernel/printk.c
index 5052b54..3a05c8a 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -105,6 +105,9 @@ static unsigned log_start; /* Index into log_buf: next char to be read by syslog
static unsigned con_start; /* Index into log_buf: next char to be sent to consoles */
static unsigned log_end; /* Index into log_buf: most-recently-written-char + 1 */
+/* Wait queue controlling the wait for a console device */
+static DECLARE_WAIT_QUEUE_HEAD(console_wait);
+
/*
* Array of consoles built from command line options (console=)
*/
@@ -1081,6 +1084,13 @@ struct tty_driver *console_device(int *index)
struct console *c;
struct tty_driver *driver = NULL;
+ /* Wait a while for a console to show up. If one doesn't show up
+ * for too long, we'll just continue without a console. */
+ if (wait_event_timeout(console_wait, preferred_console >= 0,
+ CONFIG_PRINTK_CONSOLE_WAIT) == 0)
+ pr_warning("No preferred console after waiting %u msec; "
+ "continuing anyway\n", CONFIG_PRINTK_CONSOLE_WAIT);
+
acquire_console_sem();
for (c = console_drivers; c != NULL; c = c->next) {
if (!c->device)
@@ -1230,6 +1240,7 @@ void register_console(struct console *console)
spin_unlock_irqrestore(&logbuf_lock, flags);
}
release_console_sem();
+ wake_up_all(&console_wait);
}
EXPORT_SYMBOL(register_console);
VomLehn <[email protected]> writes:
>
> History
> v2 Wait for the preferred console rather than any console. Make the
> delay interval a tunable.
CONFIG tunables are usually a bad idea. What should a binary distribution
kernel set? Better make it a boot option with a reasonable default.
Also a setting to panic in this case might be useful, normally a system
without console is not very useful and needs to be rebooted anyways.
-Andi
--
[email protected] -- Speaking for myself only.
Andi Kleen wrote:
> VomLehn <[email protected]> writes:
>> History
>> v2 Wait for the preferred console rather than any console. Make the
>> delay interval a tunable.
>
> CONFIG tunables are usually a bad idea. What should a binary distribution
> kernel set? Better make it a boot option with a reasonable default.
Your point about boot options is well taken; I released a more recent
version of this patch with boot options last Friday and would appreciate
your comments.
> Also a setting to panic in this case might be useful, normally a system
> without console is not very useful and needs to be rebooted anyways.
Umm, those of us in the embedded space have the, perhaps misguided,
notion that our systems are quite useful without consoles...
But, more to the specific point, the console code is pretty smart. If
you set your delay interval too short and the console comes up later,
you won't see output to /dev/console, but you *will* see kernel printk
output, including the message that no console could be opened. This
would, hopefully, point the user to the problem. I can also make the
message more specific about which parameter to set in that case.
>
> -Andi
On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote:
> Andi Kleen wrote:
> >VomLehn <[email protected]> writes:
> >>History
> >>v2 Wait for the preferred console rather than any console. Make the
> >> delay interval a tunable.
> >
> >CONFIG tunables are usually a bad idea. What should a binary distribution
> >kernel set? Better make it a boot option with a reasonable default.
>
> Your point about boot options is well taken; I released a more recent
> version of this patch with boot options last Friday and would appreciate
> your comments.
Ah missed that sorry.
>
> >Also a setting to panic in this case might be useful, normally a system
> >without console is not very useful and needs to be rebooted anyways.
>
> Umm, those of us in the embedded space have the, perhaps misguided,
> notion that our systems are quite useful without consoles...
That seems more like a special case that shouldn't be default?
-Andi
--
[email protected] -- Speaking for myself only.
Andi Kleen wrote:
> On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote:
>> Andi Kleen wrote:
>>> VomLehn <[email protected]> writes:
...
>>> Also a setting to panic in this case might be useful, normally a system
>>> without console is not very useful and needs to be rebooted anyways.
>> Umm, those of us in the embedded space have the, perhaps misguided,
>> notion that our systems are quite useful without consoles...
>
> That seems more like a special case that shouldn't be default?
I have to disagree. Panicing because you can't open /dev/console is
likely to mean that you get no output at all and so no chance to see a
message explaining why the open failed. If the open failure is all that
happened, the rest of the system may very well come up normally. You
would then be able to look at the kernel log and diagnose the issue.
In any case, the purpose of this patch is fix USB consoles to work as
they did before parallelized startup. This involves addressing a race
condition that, theoretically, always existed but which previously
hadn't been a problem. Changing the behavior when init_post() can't open
/dev/console seems out of scope.
> -Andi