lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 13 Feb 2010 15:35:41 +0200
From:	Anssi Hannula <anssi.hannula@....fi>
To:	Oliver Neukum <oliver@...kum.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Matthew Garrett <mjg59@...f.ucam.org>, dvomlehn@...co.com,
	gregkh@...e.de, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] "USB: use kfifo to buffer usb-generic serial writes" causes gobi_loader to hang

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists