> 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 Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
