On Tuesday 19 June 2007, Alan Stern wrote:
> On Tue, 19 Jun 2007, Yum Rayan wrote:
> 
> > Following is the patch that we received from our h/w vendor. It seems
> > to correct the issue where we are seeing the ethernet interface
> > accumulate RX errors while USB device is not actually used.
> 
> What do you mean by "not actually used"?  If it really were not being 
> used then no errors could occur.

Exactly.  It would seem this particular hardware is misbehaving.


> Evidently you mean that you encounter receive errors at times when the
> device isn't transmitting.  It's not clear how relevant that is to the 
> problem...
> 
> > We have been testing this for a while and it seems to work. Comments
> > appreciated.
> > 
> > Patch is against 2.6.16

Ancient, tough I suspect the patch would apply to 2.6.22-rc5 too.


> > Thanks.
> 
> > +               if (cc == TD_PIDCHECKFAIL || cc == TD_DEVNOTRESP) {
> > +                       urbpriv = td->urb->hcpriv;
> > +
> > +                       td->ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
> > +                       td->hwINFO &= ~cpu_to_hc32(ohci, TD_CC);
> > +                       td->hwINFO &= ~cpu_to_hc32(ohci, TD_EC);
> > +                       urb = td->urb;
> > +                       for (count = 0; count < urbpriv->length; count++) {
> > +                               td = urbpriv->td[count];
> > +                               if (td) {
> > +                                       list_del(&td->td_list);
> > +                                       td_dma =
> > +                                           hc32_to_cpup(ohci, 
> > &td->hwNextTD);
> > +                               }
> > +                       }
> > +                       list_del(&urbpriv->pending);
> > +                       td_submit_urb(ohci, urb);
> 
> My impression is that this would lead to an infinite loop when you try 
> to communicate with a non-responding device.

Regardless, it's incorrect.  The hardware is misbehaving, or else it
would neither send packets with the wrong PID, nor stop responding
entirely.

We don't put workarounds like this in the host controller drivers.
If the upper layer code isn't behaving well, that's where to fix it.

But in this case it seems like the root cause is a hardware bug.
Suggest to your vendor that they fix it, rather than trying to
work around the problem in every OS.  :)

- Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to