> But the fact that the call stack passes through qh_completions and > ehci_unlink_async means that the URB in question is _not_ isochronous > (or interrupt for that matter). Does that help? Doh. My mistake. Of course it's a bulk endpoint. This is the price I pay for working on two different USB drivers on the same day. :-) > If you want to trace things in greater detail, look at the value of > urb->use_count at various points. usb_kill_urb won't return until the > value reaches 0, which should not occur until well after > usb_hcd_unlink_urb_from_ep returns. Good suggestion. I'll add code to print it out before and after usb_kill_urb(), as well as from within the the IRQ handler and right before the call to usb_free_urb(). I was kind of hoping you would chime in and say, "Oh that? I fixed that six months ago in 3.15 via this patch." No such luck, I guess... It definitely seems to be timing sensitive. I've got a script to reproduce the problem and on average it takes anywhere from 30-80 restarts of the stream (where each restart kills and frees the URBs as well as the transfer buffer for that URB). Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
