Re: [linux-usb-devel] Re: USBDEVFS_RESET deadlocks USB bus.

["Zephaniah E. Hull" <warp@babylon.d2dc.net>]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

On Mon, Jun 07, 2004 at 09:05:41AM +0200, Duncan Sands wrote:
> > > Are you sure?  That seems impossible to me!  Can you
> > > get a new call trace please.
> > 
> > Hrm, I could have sworn that the kernel I tested with was rebuilt with
> > the patch, but now that I am trying it on rc2-mm1 with the patch, it
> > does in fact seem to be working, mostly.
> > 
> > Thanks a lot, and sorry for the previous report.
> > 
> > I seem to be seeing a locking related race condition on bulk reads and
> > writes as well, should I start a new thread for those?
> 
> I don't think it matters much whether you start a new thread or not.  What
> problem are you seeing?

To give some background, the libusb backend of pilot-link is a slightly
odd design, we do the init work, reset the device, and then setup a read
thread, which basicly does a continuous loop of bulk no-timeout reads
from USB.

In the primary thread we do most of the work, including doing the USB
bulk writes to do things like ask the pilot for information.

Which, once I had things working again, sometimes resulted in the
following issue:

lt-pilot-xfer D 00000010     0  3351   3097  3398               (NOTLB)
ca93dec0 00000082 00000001 00000010 cdaa434c caac11e8 cdaa43ec caac11a0
       ca93ded4 ce8b4318 c03a2fc0 00000000 3904f0c0 000f42ec cb7fe398 ca913c24
       00000246 ca93c000 ca93defc c0336735 ca913c2c cb7fe1f0 00000001 cb7fe1f0
Call Trace:
 [<c0336735>] __down+0x85/0x120
 [<c033692f>] __down_failed+0xb/0x14
 [<c0273245>] .text.lock.devio+0xe5/0x120
 [<c015a45d>] file_ioctl+0x5d/0x170
 [<c015a686>] sys_ioctl+0x116/0x250
 [<c0103f8f>] syscall_call+0x7/0xb

lt-pilot-xfer D 00000001     0  3398   3351                     (NOTLB)
ca8ebe1c 00000082 00000000 00000001 0ca97854 ce5bca08 d7d85000 00000001
       ce5bca08 00000246 ca8ebe2c 00000000 38200f00 000f42ec cb7fe938 ca8ebeac
       ca8ea000 ca8ea000 ca8ebe70 c0336eb8 00000000 cb7fe790 c01146a0 00000000
Call Trace:
 [<c0336eb8>] wait_for_completion+0x78/0xf0
 [<c026cc0a>] usb_start_wait_urb+0x7a/0xc0
 [<c0271866>] proc_bulk+0x116/0x220
 [<c0272f61>] usbdev_ioctl+0x581/0x710
 [<c015a45d>] file_ioctl+0x5d/0x170
 [<c015a686>] sys_ioctl+0x116/0x250
 [<c0103f8f>] syscall_call+0x7/0xb

With the device not sending us any more data until it receives the
write, and the write not getting to send until the bulk read finishes or
the device goes away.

With the predictable annoyance this causes, of course.

-- 
	1024D/E65A7801 Zephaniah E. Hull <warp@babylon.d2dc.net>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

  Yes, Java is so bulletproofed that to a C programmer it feels like
being in a straightjacket, but it's a really comfy and warm
straightjacket, and the world would be a safer place if everyone was
straightjacketed most of the time.        -- Overheard in the SDM.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]