On Fri, 27 Apr 2001, Johannes Erdfelt wrote:
> If you can, give me the output of /proc/device/uhci/hc0? That should
> help us track this down.
Ok, here we go:
I've attached a sampled trace from /proc/driver/uhci/hc0 which was
recorded in a tight loop while dd'ing from the usb driver's read(2)
(which uses queued 2 bulk-in urb's to the same ep.)
After removing redundant stuff (the whole thing samples about 1MB/sec)
I've added some comments and some debug output from the driver at the
right place.
Although I'm not really familiar with how it should look like, the
following is what makes me wondering something with the QH/TD links went
probably wrong:
------------------
Skeleton QH's
- skel_bulk_qh
[c0e1c0f0] link (00e1c092) element (00000001)
Element != First TD
0: [c0e1d1e0] link (00e1d210) e3 SPD Active Length=0 MaxLen=3f DT1 EndPt=2
Dev=2, PID=69(IN) (buf=010c2000)
1: [c0e1d210] link (00e1d240) e3 SPD Active Length=0 MaxLen=3f DT0 EndPt=2
Dev=2, PID=69(IN) (buf=010c2040)
[...]
------------------
seems qh->element is still (NULL | TERM) for some reason.
Please tell me what else might be helpful to test (or patch)!
Martin
trace of hanging queued bulk xfer
