On Mon, 18 Aug 2003, Matthias Bruestle wrote: > Somewhere inside a program run, when waiting for the interrupt data: > > HC status > usbcmd = 00c1 Maxp64 CF RS > usbstat = 0000 > usbint = 000f > usbfrnum = (0)194 > flbaseadd = 03848194 > sof = 40 > stat1 = 0095 PortEnabled PortConnected > stat2 = 0095 PortEnabled PortConnected > Frame List > Skeleton QH's > - skel_int4_qh > [c3858240] link (03858122) element (03859030) > 0: [c3859030] link (00000001) e3 SPD IOC Active NAK Length=7ff MaxLen=f DT0 > EndPt=1 Dev=5, PID=69(IN) (buf=05a5f520) > > In the second program run, the Active for Int IN is always set when an > interrupt occures.
The NAK flag above means that the HC issued the Intr IN request and the device replied with a NAK. That would explain the packets you see going across the wire. But why would the device NAK? For some reason, it must not have any interrupt data available. Or maybe there's a problem with the maxpacket size? -- the request is asking to transfer a 16-byte packet. My guess would be that in your unsuccessful run, something isn't getting initialized correctly and as a result the device doesn't queue any interrupt data. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
