On 2012.07.10 16:31, Peter Stuge wrote:
> It makes sense from the point of view of critical sections, but
> starting the timer before the transfer has actually been submitted
> would mean that the timeout while the transfer is on the bus will
> always be shorter than the user-specified timeout, off
Hey,
Hans de Goede wrote:
> doing the disarm without the flying-transfers lock held is racy, ie:
Bringing back the old behavior was a start. Yes, race also. The
attached patch on top of the previous fix avoids the race, and is
available also via
git fetch git://git.libusb.org/libusb-stuge.git fo
Hi Peter,
On 2012-07-09, at 5:28 PM, Peter Stuge wrote:
> Kevyn-Alexandre Paré wrote:
>>> Data never becomes available.
>>> The application asks the device to send data, when the application
>>> knows that data is supposed to be available in the device.
>>
>> Agree, in my case I send data to an
Hello Pete,
today, I was able to redirect the libusbx debug information (log level 4)
to a file in the test environment:
'LIBUSB_DEBUG=4 /usr/sbin/pcscd --foreground --debug --apdu &>
/var/log/pcscd.log'
Setting the log level to 4 generates huge CPU load and the log file grows very
fast (200-
Hi,
On 07/10/2012 02:40 PM, Peter Stuge wrote:
> Hans de Goede wrote:
>> I had looking further into this / writing a patch on my todo list,
>> looks like you beat me to it, thanks for working on this!
>>
>> You're patch looks good, one possible optimization would be to
>> give arm_timerfd_for_next
Hans de Goede wrote:
> I had looking further into this / writing a patch on my todo list,
> looks like you beat me to it, thanks for working on this!
>
> You're patch looks good, one possible optimization would be to
> give arm_timerfd_for_next_timeout() an extra "int stop_timer"
> argument and on
On 2012.07.10 12:18, Hans de Goede wrote:
> one possible optimization would be to
> give arm_timerfd_for_next_timeout() an extra "int stop_timer"
> argument and only call disarm_timerfd() when that argument is true.
I like that idea. I'll get on to it and submit a v2 when I get a chance.
Regards,
Hi,
On 07/10/2012 01:01 PM, Pete Batard wrote:
> I expect the attached patch to fix the likely bug reported by Hans.
>
> As previously indicated, we should be able to either rearm the next timer or
> disarm all timers in the arm_timerfd_for_next_timeout() call of io.c,
> especially as we always
On 2012.07.09 09:48, sebasti...@gmx-topmail.de wrote:
> Setting the debug level to 4 had no impact on the logging behavior of pcscd.
This is unfortunate, as we are missing a lot of information with regards
to what libusbx is doing if level 4/debug is not in use.
Especially, we still have no idea
I expect the attached patch to fix the likely bug reported by Hans.
As previously indicated, we should be able to either rearm the next
timer or disarm all timers in the arm_timerfd_for_next_timeout() call of
io.c, especially as we always issue it with the flying_transfers locked.
Note that t
10 matches
Mail list logo
