[PATCH] Wait for console to become available, v2

[PATCH] Wait for console to become available, v2

[VomLehn]

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 <dvomlehn@cisco.com>
---
 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);
 

Re: [PATCH] Wait for console to become available, v2

[Andi Kleen]

VomLehn <dvomlehn@cisco.com> 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

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Wait for console to become available, v2

[David VomLehn]

Andi Kleen wrote:
> VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Wait for console to become available, v2

[Andi Kleen]

On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote:
> Andi Kleen wrote:
> >VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> 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

-- 
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Wait for console to become available, v2

[David VomLehn]

Andi Kleen wrote:
> On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote:
>> Andi Kleen wrote:
>>> VomLehn <dvomlehn-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html