Prev: "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang
Next: crypto: make Open Firmware device id constant
From: Oliver Neukum on 19 Jan 2010 13:50 Am Dienstag, 19. Januar 2010 17:27:46 schrieb Alan Cox: > On Tue, 19 Jan 2010 16:25:36 +0100 > Johan Hovold <jhovold(a)gmail.com> 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. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 28 Jan 2010 13:50 Am Donnerstag, 28. Januar 2010 18:45:46 schrieb Greg KH: > On Tue, Jan 19, 2010 at 02:20:29PM +0100, Oliver Neukum wrote: > > Am Montag, 18. Januar 2010 21:14:16 schrieb Matthew Garrett: > > > > > drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 1565 > > > bytes > > > drivers/usb/serial/generic.c: usb_serial_generic_write - put 0 bytes > > > into fifo > > > drivers/usb/serial/generic.c: usb_serial_generic_read_bulk_callback - > > > port 0 > > > > If the FIFO is full we can do nothing. Please try the attached patch. > > Did we ever determine if the patch below is needed or not? No. Further discussion cast serious doubt on it, but we have no experimental evidence I am aware of. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 3 Feb 2010 12:30 Am Mittwoch, 3. Februar 2010 17:46:59 schrieb Matthew Garrett: > > If the FIFO is full we can do nothing. Please try the attached patch. > > Doesn't help, I'm afraid. Does anyone have any idea why the change to > use kfifo would cause this? The logic seems sound. That is unless the kfifo code is acting up. Could you printk the value kfifo_len returns in usb_serial_generic_write_start()? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 3 Feb 2010 18:00 Am Mittwoch, 3. Februar 2010 23:37:37 schrieb Matthew Garrett: > On Wed, Feb 03, 2010 at 06:21:39PM +0100, Oliver Neukum wrote: > > Am Mittwoch, 3. Februar 2010 17:46:59 schrieb Matthew Garrett: > > > > If the FIFO is full we can do nothing. Please try the attached patch. > > > > > > Doesn't help, I'm afraid. Does anyone have any idea why the change to > > > use kfifo would cause this? > > > > The logic seems sound. That is unless the kfifo code is acting up. > > Could you printk the value kfifo_len returns in usb_serial_generic_write_start()? > > kfifo_len is 4096 when it gets into the fifo_full situation. Then this won't explain it either. Do you get to the line: dbg("%s - starting IO", __func__); before it hangs? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Oliver Neukum on 7 Feb 2010 18:00
Am Freitag, 5. Februar 2010 20:58:17 schrieb Matthew Garrett: > drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0 > drivers/usb/serial/usb-serial.c: serial_write - port 0, 2048 byte(s) > drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 2048 bytes > drivers/usb/serial/generic.c: usb_serial_generic_write - put 512 bytes into fifo > drivers/usb/serial/usb-serial.c: serial_write - port 0, 1536 byte(s) > drivers/usb/serial/generic.c: usb_serial_generic_write - port 0, 1536 bytes > drivers/usb/serial/generic.c: usb_serial_generic_write - put 0 bytes into fifo > drivers/usb/serial/generic.c: usb_serial_generic_write - FIFO is full OK, could you also get an usbmon trace? This would allow a determination whether the submitted URB doesn't finish for some reason, or whether no URB is submitted, possibly because a wakeup is missed. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |