On 2012.08.03 18:08, John Chen wrote:
> I found the problem, because I was running step by step, it just timeout
> that is why I got the ABORT_PIPE, if I just ran the code directly I
> did not get ABORT_PIPE again.
Aha, that makes sense! Thanks for the update.
Regards,
/Pete
Peter,
I am in debug mode, after I steped through the
libusb_handle_events_timeout first time I notice USBTrace showed up
ABORT_PIPE , the second time I call libusb_handle_events_timeout ,
nothing showed up in the USBTrace and the callback is called.
I found the problem, because I was running st
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 A
Hi, I apologize if your guys receive this twice, it looks like my original
post did not go through. maybe I because I attached a html file?
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 fr
Hi,
> On 2012.08.03 15:51, Pete Batard wrote:
> Sebastian,
>
> can you try recompiling and installing libusbx from the latest git version?
I'll try to recompile and replace libusbx on Monday.
> On 2012.08.03 15:51, Pete Batard wrote:
> If you do observe the crash again, and since you're recompil
> list_for_each_entry() uses next as it steps through the list.
> list_for_each_entry_safe() avoids the problem by getting and saving the
> next pointer in a temporary before the loop body.
Ah right. I misread what you wrote and thought there was another issue
at hand there. Your patch looks good
Attached is my final proposal then.
On 2012.08.03 10:13, Hans de Goede wrote:
That works for me, I agree the original code is hard to read, maybe move
the refactoring to a separate patch though ?
Well, I don't really see it as refactoring, as we're moving a section of
code that used first int
Hi,
On 08/02/2012 01:28 AM, Pete Batard wrote:
> On 2012.08.01 12:52, Hans de Goede wrote:
>> Hmm, I hadn't noticed the explicit disarm there, since the
>> handle_timeouts_locked code just cancels
>> transfers and does not do anything io-intensive, the run-time for
>> handle_timeouts_locked will b
