On 06/19/2010 03:37 AM, Gary wrote: > Hi,Tim and Greg > Thanks for your information. > I used Initcall_Debug flag and found that the initialization of FFUART > takes about 4 seconds. > By tracing step by step, found the time ran away in > release_console_sem() function, located at printk.c. > I am confused why release_console_sem() took so long time. > Is there any other driver invoked release_console_sem() and did not > exited during its initializing before FFUART is initialized?
This sounds like something I've seen on other devices. Try the kernel 'quiet' option. See http://elinux.org/Disable_Console The kernel printk buffer (known internally as the "log buffer") is filled will messages throughout the execution of the kernel. However, these messages can not be printed out to the serial port until the kernel initializes the serial console. When the serial console is ready, all the messages that were previously saved in the buffer are displayed at once. From then on, each message that is "printk-ed" to the buffer is both saved in the buffer, and also immediately displayed on the console. This explains why 1) you see no messages for a little while before the console is initialized 2) why there is a long delay when the console is initialized, and the previoulsy buffered messages are drained out to the serial port (which is usually slow). BTW - what speed is your serial port? On most systems, draining the queued messages to the serial console takes less than a half second. You can avoid this delay by turning off the message output to console during booting. By using the 'quiet' option on the kernel command line, the messages are saved in the log buffer, but not displayed. They can be retrieved later using the 'dmesg' command on the target (or 'adb dmesg' on the host). If you have printk times turned on, you can see a timestamp on each message, which will allow you to see when each message was printk-ed. > Not just kernel but the whole system takes 2 minutes to boot up. > Today, I added a the same log output after do_one_initcall(*call), but > 2 minutes also are needed. > The result is different from what I have got before.It's so strange. > and while booting up, I found there are several times that no kernel > log information is outputted until after about 4 or 5 seconds. > Because there is no kernel log at the moment, I don't know what the > kernel was doing. > Maybe 2 minutes of booting time was caused by these several times of 4 > or 5 seconds. > Except for log information, Are there any other methods to know what > the kernel was doing during no-log phase of kernel booting? On some ARM systems, the kernel has the capability to print directly to the serial port (NOT going through the log buffer). These messages come out on the serial console immediately when they are output by the code, not later after buffering. Set CONFIG_DEBUG_LL and add calls to printascii, printch and printhex. Google CONFIG_DEBUG_LL for more information, and look at uses of it in the kernel source tree. I hope this helps. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Network Entertainment ============================= -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
