Hi Alan, thanks for thinking about this.
> You must have had debug set to 1, because your listing did not include the
> skeleton QH's. That's what's confusing you; the QH at dee6e210 is the
> Terminating QH.
Yup.
> It might be worthwhile examining a dump made immediately after you queue
> the problem-causing URB. Comparing that with the values after the HC has
> halted might possibly (?) point to the source of the error.
I've tracked it down to the following: the first of two queued urbs completes,
and the HC detects a problem in the following stretch of code in uhci_irq:
/* Walk the list of pending URB's to see which ones completed */
spin_lock(&uhci->urb_list_lock);
head = &uhci->urb_list;
tmp = head->next;
while (tmp != head) {
struct urb_priv *urbp = list_entry(tmp, struct urb_priv, urb_list);
struct urb *urb = urbp->urb;
tmp = tmp->next;
/* Checks the status and does all of the magic necessary */
uhci_transfer_result(uhci, urb);
}
spin_unlock(&uhci->urb_list_lock);
uhci_finish_completion(hcd, regs);
Interestingly enough, if I put a delay statement before uhci_finish_completion(hcd,
regs);
then the HC no longer barfs (*). I guessing that, in this stretch of code, links are
modified in
the wrong order so that the schedule is momentarily inconsistent; the HC spots it and
flags the error.
Ciao,
Duncan.
(*) I moved the code from uhci_free_pending_qhs(uhci); onwards in uhci_irq into
a tasklet, so as to run it with interrupts on. Otherwise, putting delay statements
in wouldn't help much in tracking down where in this lot the interrupt occurs!
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
