Re: [PATCH 1/1] tty, serial, 8250: to avoid recv fifo overrun, read rx fifo during xmit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 29, 2015 at 04:15:43PM -0700, Prasad Koya wrote:
> Hi Peter,
> 
> On Wed, Apr 29, 2015 at 3:33 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> > 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).
> >
> 
> Hardware flow control is disabled on our setups. If hardware flow
> control is supported, I see how "console=ttySx,9600n8r" could have
> helped drop/raise RTS line.

Ok, I really have almost no sympathy for systems that don't use hardware
flow control and yet expect no overruns to happen.  Come on, we learned
this decades ago that this is not a good idea.  Don't force additional
software complexity onto systems that refuse to use two hardware gpio
lines properly.

thanks,

greg k-h

--
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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux