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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
