Hi John. Your previous e-mail was received alright. It's just that the people on the list have been busy...
On 2012.08.03 06:39, John Chen wrote: > I am doing a Asynchronous Bulk call to USB, everything seems to work > fine, but after I call the first libusb_handle_events_timeout, I > Received ABORT_PIPE from USBTrace, After the second > libusb_handle_events_timeout call, the callback receive the message. > (no sure why I have to call libusb_handle_events_timeout twice before I > got the call back with that little data), I have legacy code (Windows > API) doing the same thing but I did not receive ABORT_PIPE from > USBTrace, any ideas? Are you sure libusb_handle_events_timeout() is called twice? From the debug log, it seems to be only called once (see below). > I am using VS2008, Windows 7 > > Also I have to call > err = libusb_claim_interface(this->m_handle, 0); > Before submit, do not understand why I have to do that for this > function, while other function seems to work without the above call. "You must claim the interface you wish to use before you can perform I/O on any of its endpoints." [1] The control endpoint does not require claiming, which is why you may be puzzled about suddenly having to claim to communicate with your bulk endpoint, but this is how libusbx is set to work. This is done to prevent potential concurrent access. Also as a side note (though unlikely to be the issue here) if your application is multithreaded we recommend you use libusb_handle_events_timeout_completed() rather than libusb_handle_events_timeout() [2] > The debug log is as following: > > [ 4.045232] [000006d8] libusbx: debug [libusb_claim_interface] interface 0 > [ 4.045232] [000006d8] libusbx: debug [winusb_claim_interface] claimed > interface 0 > [ 4.046232] [000006d8] libusbx: debug [libusb_get_config_descriptor] index 0 > [ 4.047232] [000006d8] libusbx: debug [windows_assign_endpoints] > (re)assigned endpoint 01 to interface 0 > [ 4.047232] [000006d8] libusbx: debug [windows_assign_endpoints] > (re)assigned endpoint 02 to interface 0 > [ 4.048232] [000006d8] libusbx: debug [windows_assign_endpoints] > (re)assigned endpoint 04 to interface 0 > [ 4.049232] [000006d8] libusbx: debug [windows_assign_endpoints] > (re)assigned endpoint 86 to interface 0 > [ 4.050232] [000006d8] libusbx: debug [windows_assign_endpoints] > (re)assigned endpoint 88 to interface 0 > [ 4.501258] [000006d8] libusbx: debug [winusb_submit_bulk_transfer] > matched endpoint 02 with interface 0 > [ 4.501258] [000006d8] libusbx: debug [winusb_submit_bulk_transfer] > writing 30 bytes > [ 4.502258] [000006d8] libusbx: debug [usbi_add_pollfd] add fd 5 events 4 Should be our transfer being added as fd #5. > [ 4.503258] [000006d8] libusbx: debug [libusb_get_next_timeout] next > timeout in 2.997276s > [ 4.505258] [000006d8] libusbx: debug > [libusb_handle_events_timeout_completed] doing our own event handling > [ 4.506258] [000006d8] libusbx: debug [handle_events] poll() 2 fds with > timeout in 1000ms If libusb_handle_events_timeout() is called twice, we should see messages such as the above twice in the debug output as well... > [ 4.507258] [000006d8] libusbx: debug [handle_events] poll() returned 1 > [ 4.508258] [000006d8] libusbx: debug [windows_handle_events] checking > fd 3 with revents = 0000 > [ 4.509258] [000006d8] libusbx: debug [windows_handle_events] checking > fd 5 with revents = 0004 > [ 4.510258] [000006d8] libusbx: debug [usbi_remove_pollfd] remove fd 5 > [ 4.510258] [000006d8] libusbx: debug [windows_transfer_callback] > handling I/O completion with errcode 0 > [ 4.511258] [000006d8] libusbx: debug [usbi_handle_transfer_completion] > transfer 005A8560 has callback 00B68CD5 I don't see anything out of the ordinary here as libusb_handle_events_timeout() seems to be called once. A few ms after the transfer was submitted, we get a poll event and handling of the completed transfer. So whatever abort occurred, it should occur after transfer completion, which your trace also seems to indicate. Can you detail how know you came to the conclusion that libusb_handle_events_timeout() was being called twice? I'm not seeing any hint of that in the log... Or are you getting the ABORT_PIPE after your very first call to handle_events, but not on subsequent ones? Looking at your code, my guess would be that you're calling libusb_cancel_transfer after completion for some reason, which results in ABORT_PIPE messages. I'd suggest that you add debug statements to print the error codes returned by each libusb call if err < 0, as it may help give us a better idea of what the problem is. Note that you can use libusb_error_name() [3] to convert the codes into an error string. Regards, /Pete [1] http://libusbx.sourceforge.net/api-1.0/group__dev.html#ga32fabedf5f13fdecf1cb33acdb19b57a [2] http://libusbx.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760b41a0cf8a4a472fbd5b [3] http://libusbx.sourceforge.net/api-1.0/group__misc.html#gacf319b823a1a1a25cc934d80db2f28c7 ------------------------------------------------------------------------------ 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
