On Tue, Dec 09, 2014 at 11:34:38PM -0800, Prasad Koya wrote: > Hi > > Below version is tested with 3.18 kernel on 16550 UART. > > - Added a new variable 'writing_to_con' to 'struct uart_8250_port'. > This would be set to 1 inside serial8250_console_write() only if > port_sysrq is 0 and oops_in_progress is 0 and "receive interrupts" are > enabled. > > - uart_console_write() is called to send out whole printk message as > earlier. wait_for_xmitr() invokes serial8250_rx_chars() only if > writing_to_con is set and if UART_LSR_DR is set. so instead of waiting > with usleep(1) it now buffers chars from receive queue. > > - if serial_8250_chars() is called with writing_to_con=1, > serial8250_rx_chars() would read one char from UART rx buffer. > > - as long as serial8250_rx_chars() does not see brk i.e., sysrq is not > set, it could buffer. if we split this functionality, driver would have > to buffer each char and flags associated with it. with this approach, > serial8250_rx_chars() will buffer "regular" chars but anything after > sysrq is left to be processed after serial8250_console_write() > returns. > > Thanks. > > > >From 46d5da6069296132d3e9f505715ab7f30701b2a5 Mon Sep 17 00:00:00 2001 > From: Prasad Koya <prasad@xxxxxxxxxx> > Date: Tue, 9 Dec 2014 22:53:31 -0800 > Subject: [PATCH 1/1] tty, serial, 8250: to avoid recv fifo overrun, read rx > fifo during xmit > > At slow baud rates, say 9600, it is easy to run into tty buffer overrun > as interrupts could get disabled for a long time. To avoid that, if > UART_LSR_DR is set, buffer char from rx fifo. Stop buffering if > port->sysrq is true. wait_for_xmitr() could pick up a byte from FIFO > (if UART_LSR_DR is set) rather than calling udelay(1). > > Signed-off-by: Prasad Koya <prasad@xxxxxxxxxx> I can't apply this if I wanted to. You need to use git-send-email to send this out, as I should not have to edit the email by hand. Also, the patch is line-wrapped and doesn't apply anyway :( 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
