On Sun, Sep 12, 2004, Alan Stern <[EMAIL PROTECTED]> wrote: > On Thu, 9 Sep 2004, Dominique Larchey wrote: > > > Here is the logs you requested ... > > I have included a commented /var/log/messages (configured to > > log kernel message) which includes logs of my driver. > > > > There are some checkpoints when network status (blocked > > or up) changed. > > > > /proc/driver/uhci/* are below once when the traffic was > > blocked because of stalled incomming URBs and once after > > traffic was up again ... > > > > Comment: /sbin/ifdown udsl0 ; /sbin/ifup udsl0 > > has the effect on unlinking all URBs and then > > resubmitting them. It does change USB status > > of the device. > > > > Dominique Larchey > > Your file dumps of /proc/driver/uhci/... proved informative. Here is what > they have to say about the first bulk-in URB: > > [caede2a0] link (0aede212) element (01623880) > 0: [c1623880] link (016238c0) e3 Length=3f MaxLen=3f DT0 EndPt=7 Dev=2, > PID=69(IN) (buf=0997a7c0) > 1: [c16238c0] link (01623900) e3 SPD Active Length=0 MaxLen=3f DT1 EndPt=7 > Dev=2, PID=69(IN) (buf=0997a800) > 2: [c1623900] link (01623940) e3 SPD Active Length=0 MaxLen=3f DT0 EndPt=7 > Dev=2, PID=69(IN) (buf=0997a840) > > Notice that TD 0 (at c1623880) has completed successfully: it's not marked > Active, Length is equal to MaxLen, and there are no error status bits set. > Its link pointer is 016238c0, the physical address of TD 1, which is still > marked Active. But! TD 1 doesn't have the NAK flag set, which means the > host controller hasn't tried to transmit it. And also, the element > pointer of the Queue Header is 01623880, which is the physical address of > TD 0, not TD 1. > > Compare that with the corresponding place in the dump for when the traffic > was flowing again: > > [caede2a0] link (0aede212) element (01623e00) > Element != First TD > 0: [c1623d80] link (01623dc0) e3 Length=3f MaxLen=3f DT1 EndPt=7 Dev=2, > PID=69(IN) (buf=0997a7c0) > 1: [c1623dc0] link (01623e00) e3 Length=3f MaxLen=3f DT0 EndPt=7 Dev=2, > PID=69(IN) (buf=0997a800) > 2: [c1623e00] link (01623e40) e3 SPD Active NAK Length=7ff MaxLen=3f DT1 > EndPt=7 Dev=2, PID=69(IN) (buf=0997a840) > 3: [c1623e40] link (01623e80) e3 SPD Active Length=0 MaxLen=3f DT0 EndPt=7 > Dev=2, PID=69(IN) (buf=0997a880) > > Here TD's 0 and 1 have completed successfully and TD 2 is running, with > the NAK flag set. Furthermore the QH element pointer holds the address of > TD 2, as it should. > > In short, your USB host controller has a hardware bug. It's supposed to > advance the QH element pointer whenever a TD completes successfully by > copying the TD's link pointer into the element pointer. But it didn't do > that when TD 0 from the first dump completed. > > I suppose it's possible that your controller isn't really broken, but > instead it has signalled a non-standard VIA-specific type of error that > the UHCI driver doesn't recognize. Since VIA has been very unhelpful > about supplying documentation and errata for their USB controllers, > there's nothing we can do about that. > > But it seems more likely that your host controller is simply broken. That > would certainly account for why you see the flow of traffic come to a > sudden stop every now and then. See if things work any better if you use > a different controller, preferably not made by VIA.
It could also be a driver bug. It has happened before. I haven't looked at the code in a long time, but we did have a bug where we were setting the element pointer incorrectly and raced with the HC updating the value. JE ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
