Dave: It seems there are some errors in the way ehci-hcd handles QH_STATE_COMPLETING. They are largely due to the fact that COMPLETING isn't a real state -- URBs can be given back either while a QH is linked or while it is unlinked (or even while it is in transition). For example, suppose the completion routine for a bulk or control URB unlinks a later URB queued for the same endpoint. Then ehci_urb_dequeue will see that qh->qh_state is QH_STATE_COMPLETING, so it will call unlink_async. But when unlink_async sees that the state isn't QH_STATE_LINKED, it will return almost immediately without doing anything. Thus qh never does get unlinked. Or suppose the completion routine for an interrupt URB unlinks a later URB queued for the same endpoint. The "switch (qh->qh_state)" statement in ehci_urb_dequeue will end up in the "default" case and will log a debugging message without doing anything else. Finally, qh_completions can be called from several different pathways. It wouldn't be surprising to see it get called recursively on occasion. And since it doesn't test for QH_STATE_COMPLETING at the start, it would run recursively, thereby messing up the list_for_each_safe() loop through the qTDs. Maybe instead of using QH_STATE_COMPLETING, a QH should contain a flag to indicate that its queue is being scanned and another flag to indicate that a rescan will be needed. What do you think? 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
