Alan Stern wrote: > Where do these URBs ever get deallocated? > ath9k_hif_usb_dealloc_rx_urbs() takes them off the anchor and kills > them, but doesn't actually deallocate them. How can I get the URBs after calling usb_kill_anchored_urbs() ? usb_get_from_anchor() would return nothing, and the driver doesn't keep track of the URBs internally. But other drivers seem to have a trick to fix this issue, during init time, a usb_free_urb() is called after submitting RX bulk URBs. This probably ensures that usb_kill_anchored_urbs() would free the URBs, since the usage reference count drops to zero. > And doesn't hif_usb_regout_cb() leak URBs in the -ENODEV, > -ESHUTDOWN, and !cmd cases? In fact, why does this routine test for > !cmd at all, given that hif_usb_send_regout() already has such a test? Agreed. I'll clean up all that. > > Any pointers on how to handle this problem of increasing 'use_count' > > would be greatly appreciated. > > You could try printing out the values of urb->use_count in > ath9k_hif_usb_rx_cb(). That might provide a clue. > > If nothing else works, use the hw_breakpoint facility to track changes > to the use_count field. Well, printing use_count in the RX callback shows the increasing value of use_count. As a hack, I tried moving the line, atomic_dec(&urb->use_count) before calling urb->complete() in usb_hcd_giveback_urb() and it fixes the issue - the use_count stays steady. Though, I have no real explanation as to why this fixes the issue. Perhaps you might have some idea. regards, Sujith -- 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
