On Tue, 10 Jun 2003, Duncan Sands wrote:
> 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:
What do you mean? The HC detects a problem only after
uhci_transfer_result() runs? Or does the next HC interrupt (with error
status) occur while this piece of code for the first interrupt is
executing?
>
> /* 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.
Notice that for bulk URBs, uhci_finish_completion() doesn't touch the
schedule at all, or at least, it doesn't touch any of the parts that the
HC looks at. Only for an isochronous transfer would it do that. You can
test this by putting a printk in uhci_remove_td() after the "goto out;"
statement -- only a TD for an iso. URB should fail to take that goto. So
I don't see how adding a delay before uhci_finish_completion() could fix
things up. It seems like that would only prolong the period during which
the schedule was inconsistent.
Furthermore, everything in uhci_transfer_result() that touches the
schedule occurs in uhci_delete_queued_urb() and uhci_remove_qh(). (In
fact, it looks like those two routines have a lot of code in common.) But
there's nothing that looks like it would make the schedule inconsistent.
It's a puzzling problem.
Alan Stern
-------------------------------------------------------
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
