Hi Prasad, On 04/29/2015 06:12 PM, Prasad Koya wrote: > On Wed, Apr 29, 2015 at 2:07 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> On Wed, Apr 29, 2015 at 04:48:01PM -0400, Peter Hurley wrote: >>> On 04/29/2015 08:30 AM, Greg KH wrote: >>>> On Wed, Apr 29, 2015 at 08:22:39AM -0400, Peter Hurley wrote: >>>>> On 04/28/2015 02:17 PM, Greg KH wrote: >>>>>> On Tue, Apr 28, 2015 at 10:44:31AM -0700, Prasad Koya wrote: >>> Basically, the boundary conditions for stable behavior can easily >>> be exceeded in several circumstances; this is one of them. >>> >>> So is trying to printk() a 1Kb log line over 9600 baud. That's nearly >>> a second with interrupts off; good luck with that. >>> > > Here is a printk outputting a little over 100 chars and an echo of 52 > chars (I tried manually to reproduce on vanilla kernel) and I see > buffer overrun. This is at 9600 baud. > > [Thu Apr 23 18:58:46 2015]Aboot# echo > abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzwatchdog_timer_fn: > watchdog_timer_fn watchdog_timer_fn watchdog_timer_fn > watchdog_timer_fn watchdog_timer_fn > [Thu Apr 23 18:58:48 2015]ttyS0: 1 input overrun(s) > > So we dont need a really large printk for this to happen. For example, > a 60 byte (very reasonable size) printk would turn off interrupts for > about 60ms at 9600 baud. During this 60ms, console input of, say, 20 > bytes could cause a 16 byte FIFO overrun during that time. True, though my statement regarding 1Kb printk() wasn't really aimed at this particular problem, but a more general statement that some things with the serial console really need to be solved elsewhere. Another idea occurred to me though: does your setup allow for hardware flow control? I ask because it would be relatively easy to drop RTS during console output (the console= command line string even allows for this to be enabled per console but it's not currently hooked up right now). Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html