On Mon, 23 Feb 2015, Devin Heitmueller wrote:
> > 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().
>
> Added a quick debug line right before the call to usb_urb_kill(),
> thinking that perhaps one of the things checked for at the top of that
> function was causing the function to return without actually doing the
> work (the function starts with a check of urb, dev, and ep for NULL).
> That said though, it looks like the usage count is screwed up. The
> URB has a usage count of zero before the call to usb_kill_urb(), and
> that's the exact URB that is referenced in the panic trace (ecb07680).
>
> Is the usage_count member an indication that the URB has gone through
> usb_submit_urb()? That it's been linked into the hardware transfer
> ring?
Here's the story:
A new URB has its use_count set to 0 by usb_init_urb.
The use_count is incremented when the URB is submitted,
in usb_hcd_submit_urb. (If the submission fails then
the use_count is decremented again.)
The use_count is decremented after the completion routine
returns, in usb_hcd_giveback_urb.
This means that an active URB should never have its use_count equal to
0. The value is normally 1; it can go up to 2 temporarily if the
completion routine resubmits the URB.
So if you see the use_count set to 0 while the URB is active, it means
that something has overwritten the value. For example, the driver
might have called usb_init_urb.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
