On 2012.06.13 12:46, Markus wrote: > Here's the log of the last good control transfer and the > consecutive one that's failing: > > [ 3.130939] [000015d8] libusbx: debug [windows_transfer_callback] handling > I/O completion with errcode 31 > [ 3.130939] [000015d8] libusbx: debug [windows_transfer_callback] detected > endpoint stall
Well, all I can say is that we seem to be getting a stall report by WinUSB indeed. That errcode is what WinUSB reports to us when it detects a stall on the bus (errcode 31 is ERROR_GEN_FAILURE, but so far I've never seen WinUSB use it for anything else but a stall report), and judging from the fact that, as far as libusbx is concerned, both transfers appear to behave the same way until it looks for the result, I think you really want to have a look at what occurs on the bus with an analyzer, as it should confirm the stall and tell you if there's anything besides wValue that has changed with the second request. If you see the expected >0x4000 wValue, and the rest of the request is the same, then the problem is likely to be with the device rather than libusbx or WinUSB. Maybe there's a special mode that needs to be enabled on the device to r/w beyond wValue 0x4000? When achievable, being able to have a look at the data being sent on the bus usually pays off, especially if you're not sure where to look to find out where the problem comes from. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
