Re: [PATCH] Wait for console to become available, v2
VomLehn dvoml...@cisco.com writes: History v2Wait 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 -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Wait for console to become available, v2
Andi Kleen wrote: VomLehn dvoml...@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. 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-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Wait for console to become available, v2
On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote: Andi Kleen wrote: VomLehn dvoml...@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. 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 -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Wait for console to become available, v2
Andi Kleen wrote: On Sun, Apr 19, 2009 at 09:23:36AM -0700, David VomLehn wrote: Andi Kleen wrote: VomLehn dvoml...@cisco.com 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-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Wait for console to become available, v2
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 dvoml...@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);
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
