On Tuesday 10 June 2003 19:18, Alan Stern wrote:
> 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?
If I put a delay statement immediately before the first line of the block of code I
pasted,
and another immediately after the last line, then the HC raises an interrupt with
process
error during the second delay statement. If I put an additional delay statement
immediately
before uhci_finish_completion(hcd, regs);, then the HC no longer signals an error!
> > /* 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.
OK, I will test that (not before Friday though).
> 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.
Yes, but completely reproducible, so it's only a matter of time before it is solved.
Ciao,
Duncan.
-------------------------------------------------------
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
