control transfers may read/write 0 bytes. That's not the issue probably. IMHO, it's likely that at some point the driver missed a td and from that point on the endpoint stalled.
On Wed, Feb 4, 2009 at 11:57 AM, <kokam...@hera.eonet.ne.jp> wrote: >> my P5K-VM machine's pci output is as follows: >> 0.26.0: usb 0c.03.00 8086/2937 10 4:0000c481 32 >> 0.26.1: usb 0c.03.00 8086/2938 3 4:0000c801 32 >> 0.26.2: usb 0c.03.00 8086/2939 5 4:0000c881 32 >> 0.29.0: usb 0c.03.00 8086/2934 5 4:0000c001 32 >> 0.29.1: usb 0c.03.00 8086/2935 10 4:0000c081 32 >> 0.29.2: usb 0c.03.00 8086/2936 5 4:0000c401 32 > > I debugged the devusv.c usbuhci.c in /sys/src/9/pc, and got the > following result, where I'm confused why the b=0x0 value of the last line. > If this is true it would write to 0!, and system hungs. It's very > reasonable, but why we get b=0x0 at dumptd()... > > Anyway the debugging outputs after I plugined a usb disk are: > > e: 95 > r: 95 > r2: 280 > r3: 80 > r: 95 0 > e: 95 > speed 1 > out [8] 80 06 00 01 00 00 08 00 > queuetd qxmit: t=f0047080 lt=f0047080 q=f0048080 first=0 last=0 > entries=00000001 > t=f0047080 q=f0048080 first=f0047080 last=f0047080 entries=00047080 > qh 0xf0048080: 0x480c2 0x1 > qh 0xf00480c0: 0x480e2 0x1 > qh 0xf00480e0: 0x480a2 0x1 > qh 0xf00480a0: 0x1 0x47060 > td 0xf0047060: l=0x47060 s=0x0 d=0x0 b=0x0 0x0 f=0x0 > s=,ep=0,d=0,D=0 > > here stalls. > > The functions used are: > portenable()-->portreset()-->portenable()-->write()-->qxmit()-->queuetd() > -->dumpqh()-->dumptd() > > I touched some on usb device long time ago, and now forgot all > because of my aging efect. > > If someone point me the place reporting wrong values, please > let me know it. > > Thanks inadvance > > Kenji > > >
