> uart_throttle/uart_unthrottle is called from a workqueue. > If the system is busy, and the uart receive lot's of data, we fill the tty > buffer, but the workqueue doesn't run and we never have a chance to call > uart_throttle. So the uart is never slow down. You should have around 64K of buffering (actually n_tty worst case should be 63.5Kbyte) that's a lot of slack so what is holding off the work queue for so long on your problem system ? I think that should be answered first as it sounds like some other part of your kernel is misbehaving. > A workaround could be to check the buffer threshold in tty_flip_buffer_push and > call throttle callback if needed. tty_flip_buffer_push can be called from an IRQ, the throttle callback needs to be able to sleep. What might work if it is needed though is to provide a tty_is_throttled() method that a driver can use to check the instantaneous throttle state. Trouble is that will require a lot of care on the drivers part to deal with asynchronus throttle/unthrottle events while peering at the state in its IRQ handler as well. Anyway - question for the case you hit, what tasks or work held off the serial work queue for 63.5Kbytes of data ? -- 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
