> On 12 Sep 2016, at 18:14, Richard Cochran <richardcoch...@gmail.com> wrote:
> On Mon, Sep 12, 2016 at 02:52:03PM +0100, Kieran Tyrrell wrote:
>> I agree. Previously I was finding that sending the signals directly
>> from ptp_clock_event unreliable (around 1 in 1,000,000 signals
>> seemed to be getting lost) while from a work queue they all arrived
>> safely. After further debugging I’m not sure if the problem was with
>> the PTP module, the igb module, my test code, or even my
>> PC. (running the same posix timer tests on the MONOTONIC clock
>> occasionally produces kernel log messages hrtimer:interrupt took
>> 3193ns).
> Something is fishy, yes, but we should get to the bottom of it.  I can
> help test this once you drop the work queue.
> I have seen the interrupts on the i210 get stuck when stressing the
> input time stamp function with a 1 kHz input.  The interrupts simply
> stop triggering.  But your issue sounds different.

My signal delivery problem was a bug in the igb interrupt handler, where I was 
assuming I could set a new trigger time for TT0 before acknowledging the 
interrupt. Turns out I have to disable TT0, acknowledge the interrupt, program 
the new trigger time, and then re-enable TT0 for it to work. All timer signals 
are now delivered synchronously and reliably.

Linuxptp-devel mailing list

Reply via email to