From: Olivier Sobrie > Hi David, > > On Mon, Jul 07, 2014 at 09:13:53AM +0000, David Laight wrote: > > From: Olivier Sobrie > > > When the module sends bursts of data, sometimes a deadlock happens in > > > the hso driver when the tty buffer doesn't get the chance to be flushed > > > quickly enough. > > > > > > To avoid this, first, we remove the endless while loop in > > > put_rx_bufdata() which is the root cause of the deadlock. > > > Secondly, when there is no room anymore in the tty buffer, we set up a > > > timer of 100 msecs to give a chance to the upper layer to flush the tty > > > buffer and make room for new data. > > > > What is the timer for? > > You need to get the sending code woken up by the urb completion. > > In put_rxbuf_data() (which can be called under irq disabled), > tty_flip_buffer_push() is called and schedules a push of the tty buffer. > When the buffer is full, I give some time to the above layer in order > to flush it. > The timer is used to recall put_rxbuf_data_and_resubmit_bulk_urb() > later in order to read the remaining data stored in > "urb->transfer_buffer" and then to resubmit the urb to receive more data > from the gsm module. > I don't understand what you mean by "getting the sending code woken up". > Calling tty_port_tty_wakeup()?? We are in the receive path... Sorry, it isn't at all clear from the general description whether you are referring to the transmit or receive path. 'flush' can mean all sorts of things ... In either case a 100ms delay to data doesn't seem right at all. David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
