Robin Getz wrote: > - late crash analysis - Sometimes - even after the kernel is up > and running properly - a device driver does a bad thing. > Normally - complete kernel dumps can come out a serial > console, and you can you your favourite serial application > to scroll back and determine what is going on. > > In many embedded devices - this is not a possibility, since > all the serial ports are in use (Irda, Bluetooth, GPS, etc). There's another thing with serial ports: In embedded devices, I've seen serial drivers hooked up to the console output either synchronously or asynchronously. Synchronously, every printk() waits to be sent to the serial port, and this slows the kernel down in normal operation, and especially boot time. Asynchronously, every printk() does into the log buffer without delay, and is sent over the serial port as fast as that can. It doesn't slow the kernel down much. When it's done asynchronously, if the kernel crashes you don't always get the last output prior to the crash, even with a serial terminal listening in your lab. But if you do it synchronously, it slows things down. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
