Re: [REGRESSION] "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang

[Anssi Hannula <anssi.hannula@iki.fi>]

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