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 17 Jan 2010 04:20 Am Sonntag, 17. Januar 2010 03:55:35 schrieb Matthew Garrett: > gobi_loader writes firmware to gobi USB devices (qcserial) via the USB > serial layer by writing it a megabyte at a time (matching the Windows > driver behaviour). Commit 8e8dce065088833fc418bfa5fbf035cb0726c04c > breaks it - strace shows the write simply hanging. ssyrq-t says the > backtrace is: > > Jan 17 15:37:37 localhost kernel: Call Trace: > Jan 17 15:37:37 localhost kernel: [<ffffffff8128986c>] n_tty_write+0x2da/0x351 > Jan 17 15:37:37 localhost kernel: [<ffffffff810464b4>] ? default_wake_function+0x0/0x14 > Jan 17 15:37:37 localhost kernel: [<ffffffff81286969>] tty_write+0x19d/0x245 > Jan 17 15:37:37 localhost kernel: [<ffffffff81289592>] ? n_tty_write+0x0/0x351 > Jan 17 15:37:37 localhost kernel: [<ffffffff81103e44>] vfs_write+0xae/0x10b > Jan 17 15:37:37 localhost kernel: [<ffffffff81103f61>] sys_write+0x4a/0x6e > Jan 17 15:37:37 localhost kernel: [<ffffffff81009e45>] tracesys+0xd9/0xde Hi, please load usbserial with debug=1 and post the output of just before the hang. 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 18 Jan 2010 12:30 Am Montag, 18. Januar 2010 02:58:44 schrieb Matthew Garrett: > drivers/usb/serial/generic.c: usb_serial_generic_write - port 0 > drivers/usb/serial/usb-serial.c: serial_write - port 0, 1536 byte(s) > drivers/usb/serial/generic.c: usb_serial_generic_write - port 0 > drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0 > drivers/usb/serial/usb-serial.c: serial_write - port 0, 1536 byte(s) > drivers/usb/serial/generic.c: usb_serial_generic_write - port 0 Hi, it is not conclusive. Can you apply the attached patch and try again? Regards Oliver
From: Oliver Neukum on 19 Jan 2010 08:30 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. Regards Oliver
From: Oliver Neukum on 19 Jan 2010 09:00 Am Dienstag, 19. Januar 2010 14:29:34 schrieb Alan Cox: > On Tue, 19 Jan 2010 14:20:29 +0100 > Oliver Neukum <oliver(a)neukum.org> 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. > > If the FIFO is full how are we getting called - we should have throttled > earlier if there is any flow control (including 'look no URBs' cases) ? The log shows no call to usb_serial_generic_write_room() Do you consider this a bug in the tty layer? 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 19 Jan 2010 10:20
Am Dienstag, 19. Januar 2010 15:21:24 schrieb Alan Cox: > > > > If the FIFO is full we can do nothing. Please try the attached patch. > > > > > > If the FIFO is full how are we getting called - we should have throttled > > > earlier if there is any flow control (including 'look no URBs' cases) ? > > > > The log shows no call to usb_serial_generic_write_room() > > Do you consider this a bug in the tty layer? > > Some of the line disciplines just throw data at the board but not n_tty > (the normal one) - so for PPP you wouldn't see checks on room but the > loader I assume is using the normal tty layer - if so something is up > because the ldisc shouldn't have written more than there is room for. I don't know which line discipline is used. Matthew? But anyway, if this can happen buglessly, the generic function must handle it. 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/ |