On Tue, Jan 19, 2010 at 07:44:54PM +0100, Oliver Neukum wrote: > Am Dienstag, 19. Januar 2010 17:27:46 schrieb Alan Cox: > > On Tue, 19 Jan 2010 16:25:36 +0100 > > Johan Hovold <jhovold@xxxxxxxxx> wrote: > > > > Is it really a fix? If the fifo is already full the write urb should be > > > in use and Oliver's patch would amount to only a minor optimisation as > > > usb_serial_generic_write_start would return 0 anyway. > > > > IF the write returns a zero then it will sleep in n_tty waiting for a > > wakeup when the FIFO level drops sufficiently. If that isn't working > > check that all cases where data is cleared from the FIFO called > > tty_wakeup and do so *after* the FIFO has been partly emptied and the > > locking has ensured the space is visible to the write side. > > > usb_serial_generic_write_bulk_callback() always calls the softint > in the single URB case. Therefore the test with the patch I sent. > It is unlikely to be chance that the hang happens just as the FIFO > is full. But that is the correct behaviour: for every kfifo_get, exactly one urb is submitted and on completion softint (tty_wake) is called. I guess we could call softint from usb_serial_generic_write_start (after the kfifo_get is made) but we would still have a 1-1 mapping. In the log posted earlier everything looks fine with respect to fifo put/get. What is apparent though is that the last write urb submitted never completes (and consequently, the writing process is never woken). And by the way, as the application in question is doing megabyte writes at a time, isn't the fifo quite likely to be full most of the time? /Johan -- 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
