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.
Alan Stern
-------------------------------------------------------
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
