Re: [Patch] Wait for console to become available, ver 3
Hi! 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 from init have no standard in/out/error 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 is 1000 msec (1 second). There are two new command line parameters: consolewait Wait forever for a console to be registered consoledelay=msec Use the given number of milliseconds as the delay interval instead of the default Could you use rootfsdelay for this? Root needs to be mounted for init to run, so...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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, ver 3
On Fri, 17 Apr 2009 14:31:48 -0700 David VomLehn dvoml...@cisco.com wrote: 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 from init have no standard in/out/error 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 is 1000 msec (1 second). There are two new command line parameters: consolewait Wait forever for a console to be registered consoledelay=msec Use the given number of milliseconds as the delay interval instead of the default This is all pretty nasty, isn't it? Let's step back for a bit from any implementation and ask what is the ideal behaviour? I think it's one of a) we permit init_post()'s open() to succeed. Console output is buffered by the kernel (could be in the printk log_buf). When the initial console is eventually registered, we flush all the queued characters into it. b) we block in init_post(), waiting for the initial console to become available. I think b) is better. Simpler, safer, less likely for information loss if the kernel were to crash in that delay window. Am I right? Did I miss any options? If we want b) then how to do it? One possibility: the initcalls have been completed when init_post() is called. How about: if one of those initcalls will be asynchronously registering a console, it should inform the console layer about this. It should call the new i_will_be_adding_a_console_soon() function within its initcall. The console subsystem will remember this, and we can cause init_post() to block until that registration has occurred. We'll need to be able to handle errors, and we'll need to be able to handle the case where the initcall function isn't sure whether or not it will be registering a console. So there will also need to be an oops_im_not_adding_a_console_after_all() function, which will withdraw the effects of i_will_be_adding_a_console_soon(). Which means that i_will_be_adding_a_console_soon() will need to return a handle for the oops_im_not_adding_a_console_after_all() caller to pass. If init_post() is currently blocked awaiting the arrival of the console, oops_im_not_adding_a_console_after_all() will unblock init_post() if there are no more potential console registrations pending, and inti_post()'s attempt to open a console will fail. Or something like that? -- 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, ver 3
On Mon, 20 Apr 2009, Andrew Morton wrote: If we want b) then how to do it? One possibility: the initcalls have been completed when init_post() is called. How about: if one of those initcalls will be asynchronously registering a console, it should inform the console layer about this. It should call the new i_will_be_adding_a_console_soon() function within its initcall. The console subsystem will remember this, and we can cause init_post() to block until that registration has occurred. We'll need to be able to handle errors, and we'll need to be able to handle the case where the initcall function isn't sure whether or not it will be registering a console. So there will also need to be an oops_im_not_adding_a_console_after_all() function, which will withdraw the effects of i_will_be_adding_a_console_soon(). Which means that i_will_be_adding_a_console_soon() will need to return a handle for the oops_im_not_adding_a_console_after_all() caller to pass. If init_post() is currently blocked awaiting the arrival of the console, oops_im_not_adding_a_console_after_all() will unblock init_post() if there are no more potential console registrations pending, and inti_post()'s attempt to open a console will fail. Or something like that? What if a subsystem simply doesn't know in advance whether or not it's going to register a console? Or doesn't know when it has finished probing all devices (since a new device could be plugged in at any time)? Not to mention that this scheme appears more complicated than the one it's intended to replace... although it doesn't have any boot-line parameters. Personally, I'm in favor of adding a boot parameter. Things could be simplified slightly by treating a negative value (or a missing value) as indicating an infinite timeout; then only one new parameter would be needed instead of two. Alan Stern -- 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, ver 3
On Mon, 20 Apr 2009 17:51:16 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: On Mon, 20 Apr 2009, Andrew Morton wrote: If we want b) then how to do it? One possibility: the initcalls have been completed when init_post() is called. How about: if one of those initcalls will be asynchronously registering a console, it should inform the console layer about this. It should call the new i_will_be_adding_a_console_soon() function within its initcall. The console subsystem will remember this, and we can cause init_post() to block until that registration has occurred. We'll need to be able to handle errors, and we'll need to be able to handle the case where the initcall function isn't sure whether or not it will be registering a console. So there will also need to be an oops_im_not_adding_a_console_after_all() function, which will withdraw the effects of i_will_be_adding_a_console_soon(). Which means that i_will_be_adding_a_console_soon() will need to return a handle for the oops_im_not_adding_a_console_after_all() caller to pass. If init_post() is currently blocked awaiting the arrival of the console, oops_im_not_adding_a_console_after_all() will unblock init_post() if there are no more potential console registrations pending, and inti_post()'s attempt to open a console will fail. Or something like that? What if a subsystem simply doesn't know in advance whether or not it's going to register a console? Or doesn't know when it has finished probing all devices (since a new device could be plugged in at any time)? Fix it. It's trivial to make a sub-driver call back into a higher layer to tell it that it registered a console. Or just do the i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all() calls from the layer which _does_ know. Not to mention that this scheme appears more complicated than the one it's intended to replace... although it doesn't have any boot-line parameters. It isn't very complicated. Yes, a boot parameter is simple to inplement. But it's ghastly from a usability POV. Especially if you care about boot times. For how long do you delay? The user has to experiment with different delays until he finds the magic number. Then he adds 10% and waits for the inevitable failure reports to come in. It's much better to just get it right, even if that makes it more complex. -- 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, ver 3
Personally, I'm in favor of adding a boot parameter. Things could be simplified slightly by treating a negative value (or a missing value) as indicating an infinite timeout; then only one new parameter would be needed instead of two. I'm allergic to the idea of a user interface using negative one to mean infinity. It's an bizzare idea that makes sense only to programming wankers. Such as ourselves. Having a missing value mean infinitity is a not whole lot better. I do agree with the idea of adding one boot parameter rather than two. How about keeping the consoledelay parameter, but allow it to either take a string, such as forever, or an integer, which is the number of milliseconds to delay? I think that will make sense to a lot more people. Note that, as far as the implementation goes, using a -1 to mean an infinite wait may very well make sense. I just don't think it makes sense where decent people can see it. -- David VomLehn -- 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, ver 3
On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote: On Mon, 20 Apr 2009 17:51:16 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: ... What if a subsystem simply doesn't know in advance whether or not it's going to register a console? Or doesn't know when it has finished probing all devices (since a new device could be plugged in at any time)? Fix it. It's trivial to make a sub-driver call back into a higher layer to tell it that it registered a console. Or just do the i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all() calls from the layer which _does_ know. In the case of the console, we already have register_console(), which is what I'm using. I think your proposal will require adding code all over the place. And buses such as USB simply have no way of knowing whether they are done enumerating devices. A new device could take hours to come on line. Yes, a boot parameter is simple to inplement. But it's ghastly from a usability POV. Especially if you care about boot times. For how long do you delay? The user has to experiment with different delays until he finds the magic number. Then he adds 10% and waits for the inevitable failure reports to come in. It's much better to just get it right, even if that makes it more complex. With USB, you just can't *ever* get it right. There is no limit on how long a device has to tell you its there. I wish this weren't the case, but our good friends in the USB world tell us that we have been lucky to have had USB consoles work as long as they have. -- David VomLehn -- 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, ver 3
On Mon, 20 Apr 2009 15:35:00 -0700 David VomLehn dvoml...@cisco.com wrote: On Mon, Apr 20, 2009 at 03:14:00PM -0700, Andrew Morton wrote: On Mon, 20 Apr 2009 17:51:16 -0400 (EDT) Alan Stern st...@rowland.harvard.edu wrote: ... What if a subsystem simply doesn't know in advance whether or not it's going to register a console? Or doesn't know when it has finished probing all devices (since a new device could be plugged in at any time)? Fix it. It's trivial to make a sub-driver call back into a higher layer to tell it that it registered a console. Or just do the i_will_be_adding_a_console_soon()/oops_im_not_adding_a_console_after_all() calls from the layer which _does_ know. In the case of the console, we already have register_console(), which is what I'm using. I think your proposal will require adding code all over the place. And buses such as USB simply have no way of knowing whether they are done enumerating devices. A new device could take hours to come on line. Add a timeout parameter to i_will_be_adding_a_console_soon(). (This means that the how-long-to-wait-for policy is probably ahrd-coded into the kernel which might be a problem). Yes, a boot parameter is simple to inplement. But it's ghastly from a usability POV. Especially if you care about boot times. For how long do you delay? The user has to experiment with different delays until he finds the magic number. Then he adds 10% and waits for the inevitable failure reports to come in. It's much better to just get it right, even if that makes it more complex. With USB, you just can't *ever* get it right. There is no limit on how long a device has to tell you its there. I wish this weren't the case, but our good friends in the USB world tell us that we have been lucky to have had USB consoles work as long as they have. Sigh, OK, I appreciate the problem better. But the proposed solution is really quite fragile. I expect that it will only prove usable in highly controlled hardware setups. Is my option a) any use? -- 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, ver 3
On Mon, Apr 20, 2009 at 03:35:00PM -0700, David VomLehn wrote: With USB, you just can't *ever* get it right. There is no limit on how long a device has to tell you its there. I wish this weren't the case, but our good friends in the USB world tell us that we have been lucky to have had USB consoles work as long as they have. Lucky? You all are _more_ than lucky. USB consoles was a bad hack written on a drunken dare. I'm still constantly amazed that the thing even works at all, let alone the fact that people are actually using it :) The things I agree to over beers, you would think I would learn... thanks, greg k-h -- 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, ver 3
David VomLehn wrote: + consoledelay=mS [KNL] Wait up to mS milliseconds for the a preferred + console to be registered, then continue. Useful for + systems where a console may not be plugged in, such as + for USB serial devices. + Pet peeve: The symbol for millisecond is ms. mS is a unit of conductance, millisiemens. -hpa -- 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
