"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 21 Feb 2010 17:20 Am Sonntag, 21. Februar 2010 22:28:54 schrieb Alan Stern: > > > This is again with the gobi_loader with extra sleep added in the beginning. > > > Otherwise it hangs (which is the actual original problem). > > > > That log makes sure that the final cancellation comes from closing > > the file. Is that a log of a working run? > > Could this simply be one of those cases where the device file is closed > just after the final write URB is submitted but before it can complete, > so the URB gets cancelled and the data isn't transferred? It looks likely, but why doesn't a delay fix 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/
From: Anssi Hannula on 21 Feb 2010 18:10 On maanantai 22 helmikuu 2010 00:12:36 Oliver Neukum wrote: > Am Sonntag, 21. Februar 2010 22:42:12 schrieb Anssi Hannula: > > And of course this doesn't explain why it hangs (and the WARNING) if I > > remove the sleep calls I added in gobi_loader. > > Please tell us where you put a delay. As I said earlier, the delay was put *before* most of the data gets written. More specifically, I inserted a delay of one second between transmission of magic1 and magic2, one between magic2 and magic3, and one between magic3 and the first firmware file. If I additionally insert a one-second delay before the fd is closed, I get this usbmon log: http://stuff.onse.fi/gobi2000/gobi-regression5.mon.log The firmware upload is still unsuccessful. -- 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 21 Feb 2010 18:20 On maanantai 22 helmikuu 2010 01:06:36 Anssi Hannula wrote: > On maanantai 22 helmikuu 2010 00:12:36 Oliver Neukum wrote: > > Am Sonntag, 21. Februar 2010 22:42:12 schrieb Anssi Hannula: > > > And of course this doesn't explain why it hangs (and the WARNING) if I > > > remove the sleep calls I added in gobi_loader. > > > > Please tell us where you put a delay. > > As I said earlier, the delay was put *before* most of the data gets > written. > > More specifically, I inserted a delay of one second between transmission of > magic1 and magic2, one between magic2 and magic3, and one between magic3 > and the first firmware file. > > If I additionally insert a one-second delay before the fd is closed, I get > this usbmon log: > http://stuff.onse.fi/gobi2000/gobi-regression5.mon.log > > The firmware upload is still unsuccessful. If I use the option driver instead of qcserial, the firmware upload is always successful (without any added delays needed). The usbmon log for that case can be found here: http://stuff.onse.fi/gobi2000/gobi-regression6.mon.log -- 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 21 Feb 2010 18:30 On maanantai 22 helmikuu 2010 01:13:35 Anssi Hannula wrote: > On maanantai 22 helmikuu 2010 01:06:36 Anssi Hannula wrote: > > On maanantai 22 helmikuu 2010 00:12:36 Oliver Neukum wrote: > > > Am Sonntag, 21. Februar 2010 22:42:12 schrieb Anssi Hannula: > > > > And of course this doesn't explain why it hangs (and the WARNING) if > > > > I remove the sleep calls I added in gobi_loader. > > > > > > Please tell us where you put a delay. > > > > As I said earlier, the delay was put *before* most of the data gets > > written. > > > > More specifically, I inserted a delay of one second between transmission > > of magic1 and magic2, one between magic2 and magic3, and one between > > magic3 and the first firmware file. > > > > If I additionally insert a one-second delay before the fd is closed, I > > get this usbmon log: > > http://stuff.onse.fi/gobi2000/gobi-regression5.mon.log > > > > The firmware upload is still unsuccessful. > > If I use the option driver instead of qcserial, the firmware upload is > always successful (without any added delays needed). The usbmon log for > that case can be found here: > http://stuff.onse.fi/gobi2000/gobi-regression6.mon.log I installed 2.6.31.12 to get a usbmon log with qcserial before the regression as well (without delays, upload successful): http://stuff.onse.fi/gobi2000/gobi-regression7.mon.log -- 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 22 Feb 2010 13:40
On maanantai 22 helmikuu 2010 17:28:36 Alan Stern wrote: > On Mon, 22 Feb 2010, Anssi Hannula wrote: > > > > If I additionally insert a one-second delay before the fd is closed, > > > > I get this usbmon log: > > > > http://stuff.onse.fi/gobi2000/gobi-regression5.mon.log > > > > > > > > The firmware upload is still unsuccessful. > > > > > > If I use the option driver instead of qcserial, the firmware upload is > > > always successful (without any added delays needed). The usbmon log for > > > that case can be found here: > > > http://stuff.onse.fi/gobi2000/gobi-regression6.mon.log > > > > I installed 2.6.31.12 to get a usbmon log with qcserial before the > > regression as well (without delays, upload successful): > > http://stuff.onse.fi/gobi2000/gobi-regression7.mon.log > > The major difference between the logs is in the way the data get > divided up into packets. In both the successful logs, there are > sequences of bulk-OUT packets with lengths like: > > 44, 1, 15, 1, 13 > > where the unsuccessful transfer just has a single packet of length 74. > Also, the successful transfers show a lot of bulk-IN traffic where the > unsuccessful transfer doesn't have any. I don't know if that is > relevant, however. > > No other differences stand out. I guess that would suggest that the device doesn't allow the initialization data to be broken into packets arbitrarily (though some differences seem allowed, as the windows driver transmits them differently). Does this mean a tty interface is ill-suited for the microcode upload, and instead qcserial should use the kernel's generic microcode upload mechanism or the userspace should use libusb to do it? Any idea what could be causing the hang, then? The WARNING that appears when interrupting the hung gobi_loader is for serial_unthrottle() being called while usb_serial_port->port.count == 0. -- 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/ |