"USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang
in [Kernel]
|
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 8 Feb 2010 14:10 Am Freitag, 5. Februar 2010 22:35:55 schrieb Matthew Garrett: > Full log is at http://www.codon.org.uk/~mjg59/gobi_log.gz I'm getting a 404. 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 13 Feb 2010 02:20 Am Samstag, 13. Februar 2010 03:50:04 schrieb Alan Stern: > On Sat, 13 Feb 2010, Anssi Hannula wrote: > > > On 05.02.2010 23:59, Oliver Neukum wrote: > > > 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. > > > > I'm also affected by this regression. Here's an usbmon trace of > > gobi_loader hanging: > > http://stuff.onse.fi/gobi2000/gobi-regression.mon.log > > That's odd. The log shows the final bulk-OUT transfer was cancelled > after less than 1 ms. Is there a timeout value somewhere that is too > small by a factor of 1000? Neither qcserial nor usb-serial implement timeouts. Is it possible that this is caused by user space closing the handle causing usb-serial::port_release() to call kill_traffic()? Anssi, going by your log the last write is quite short and begins with 342d3030 39202020 20202020 20202020 801d9b80 02000000 3512dcfe 44313032. Does this match with the last part of the firmware you are transfering? Could you put an "mdelay(500);" at the beginning of usb-serial::port_release() and retest? 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: Anssi Hannula on 13 Feb 2010 08:40 On lauantai 13 helmikuu 2010 09:11:36 Oliver Neukum wrote: > Am Samstag, 13. Februar 2010 03:50:04 schrieb Alan Stern: > > On Sat, 13 Feb 2010, Anssi Hannula wrote: > > > On 05.02.2010 23:59, Oliver Neukum wrote: > > > > 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. > > > > > > I'm also affected by this regression. Here's an usbmon trace of > > > gobi_loader hanging: > > > http://stuff.onse.fi/gobi2000/gobi-regression.mon.log > > > > That's odd. The log shows the final bulk-OUT transfer was cancelled > > after less than 1 ms. Is there a timeout value somewhere that is too > > small by a factor of 1000? > > Neither qcserial nor usb-serial implement timeouts. > Is it possible that this is caused by user space closing the handle > causing usb-serial::port_release() to call kill_traffic()? > > Anssi, going by your log the last write is quite short and begins > with 342d3030 39202020 20202020 20202020 801d9b80 02000000 3512dcfe > 44313032. Does this match with the last part of the firmware you are > transfering? Yes. (there are three files, this is the last part of the third file) > Could you put an "mdelay(500);" at the beginning of > usb-serial::port_release() and retest? It seems I can't get that far anymore, it hangs much more early now: http://stuff.onse.fi/gobi2000/gobi-regression2.mon.log After interrupting gobi_loader I get a WARNING: http://stuff.onse.fi/gobi2000/gobi-regression2.warning.log Trying gobi_loader again immediately, the log is almost empty: http://stuff.onse.fi/gobi2000/gobi-regression3.mon.log After reboot I get a similar log as regression2: http://stuff.onse.fi/gobi2000/gobi-regression4.mon.log Actually, just now I noticed that the first time I had some extra sleep calls before starting the firmware upload in gobi_loader, which caused it to successfully finish (i.e. not hang; I guess somehow I didn't notice it when I logged the first usbmon.log), but the firmware wasn't still uploaded properly (that'd be because of the cancelled transfer I guess). I'll get back to this later today, including testing with mdelay in port_release with the extra sleep calls in gobi_loader. -- Anssi Hannula -- 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: Anssi Hannula on 13 Feb 2010 14:10 On lauantai 13 helmikuu 2010 15:35:41 Anssi Hannula wrote: > On lauantai 13 helmikuu 2010 09:11:36 Oliver Neukum wrote: > > Am Samstag, 13. Februar 2010 03:50:04 schrieb Alan Stern: > > > On Sat, 13 Feb 2010, Anssi Hannula wrote: > > > > On 05.02.2010 23:59, Oliver Neukum wrote: > > > > > 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. > > > > > > > > I'm also affected by this regression. Here's an usbmon trace of > > > > gobi_loader hanging: > > > > http://stuff.onse.fi/gobi2000/gobi-regression.mon.log > > > > > > That's odd. The log shows the final bulk-OUT transfer was cancelled > > > after less than 1 ms. Is there a timeout value somewhere that is too > > > small by a factor of 1000? > > > > Neither qcserial nor usb-serial implement timeouts. > > Is it possible that this is caused by user space closing the handle > > causing usb-serial::port_release() to call kill_traffic()? > > > > Anssi, going by your log the last write is quite short and begins > > with 342d3030 39202020 20202020 20202020 801d9b80 02000000 3512dcfe > > 44313032. Does this match with the last part of the firmware you are > > transfering? > > Yes. (there are three files, this is the last part of the third file) > > > Could you put an "mdelay(500);" at the beginning of > > usb-serial::port_release() and retest? > > It seems I can't get that far anymore, it hangs much more early now: > http://stuff.onse.fi/gobi2000/gobi-regression2.mon.log > After interrupting gobi_loader I get a WARNING: > http://stuff.onse.fi/gobi2000/gobi-regression2.warning.log > Trying gobi_loader again immediately, the log is almost empty: > http://stuff.onse.fi/gobi2000/gobi-regression3.mon.log > After reboot I get a similar log as regression2: > http://stuff.onse.fi/gobi2000/gobi-regression4.mon.log > > Actually, just now I noticed that the first time I had some extra sleep > calls before starting the firmware upload in gobi_loader, which caused it > to successfully finish (i.e. not hang; I guess somehow I didn't notice it > when I logged the first usbmon.log), but the firmware wasn't still > uploaded properly (that'd be because of the cancelled transfer I guess). > > I'll get back to this later today, including testing with mdelay in > port_release with the extra sleep calls in gobi_loader. port_release is only called when the serial device is removed, so this has no effect here. -- Anssi Hannula -- 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 15 Feb 2010 08:10
Am Samstag, 13. Februar 2010 20:01:54 schrieb Anssi Hannula: > > I'll get back to this later today, including testing with mdelay in > > port_release with the extra sleep calls in gobi_loader. > > port_release is only called when the serial device is removed, so this has no > effect here. But something must kill your last URB. You are not using autosuspend are you? Can load usbserial with "debug=1"? 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/ |