1. 11 Oct, 2018 2 commits
  2. 10 Oct, 2018 2 commits
  3. 30 Aug, 2018 3 commits
  4. 14 Dec, 2017 1 commit
  5. 01 Dec, 2017 4 commits
  6. 06 Jul, 2017 7 commits
  7. 03 Jul, 2017 1 commit
  8. 30 Jun, 2017 2 commits
  9. 22 Jun, 2017 3 commits
    • Alessandro Rubini's avatar
      syslog: tell not-critical track-lost events · 9d04f61f
      Alessandro Rubini authored
      Under frame loss, most track-lost are just because of ptp timeouts.
      But since the underlying pll is unaffected, and the RTT is almost constant,
      we can tell in the logs whether the lost/resync was actually a time
      jump or not.
      
      This is what happens with moderate frame loss (fhe first track-lost is
      real, due to a ptp restart, the following ones are not and max delta
      between calculated setpoint and current setpoint is reported):
      
         Jan  1 00:00:02 192.168.128.84 (00: 26:7b:00:04:27) Node up since 1 seconds
         Jun 12 14:16:06 192.168.128.84 Tracking after 19.141 s
         Jun 12 14:17:14 192.168.128.84 Lost track
         Jun 12 14:17:20 192.168.128.84 2-th re-rtrack after 6.119 s
         Jun 12 14:17:43 192.168.128.84 Lost track
         Jun 12 14:17:46 192.168.128.84 3-th re-rtrack after 3.287 s (max delta 2 ps)
         Jun 12 14:18:48 192.168.128.84 Lost track
         Jun 12 14:19:00 192.168.128.84 4-th re-rtrack after 12.388 s (max delta 0 ps)
         Jun 12 14:19:14 192.168.128.84 Lost track
         Jun 12 14:19:18 192.168.128.84 5-th re-rtrack after 4.126 s (max delta 3 ps)
         Jun 12 14:19:25 192.168.128.84 Lost track
         Jun 12 14:19:31 192.168.128.84 6-th re-rtrack after 6.022 s (max delta 4 ps)
         Jun 12 14:19:36 192.168.128.84 Lost track
         Jun 12 14:19:38 192.168.128.84 7-th re-rtrack after 2.229 s (max delta 1 ps)
         Jun 12 14:19:52 192.168.128.84 Lost track
         Jun 12 14:20:03 192.168.128.84 8-th re-rtrack after 10.997 s (max delta 1 ps)
         Jun 12 14:21:02 192.168.128.84 Lost track
         Jun 12 14:21:21 192.168.128.84 9-th re-rtrack after 18.906 s (max delta 2 ps)
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      9d04f61f
    • Alessandro Rubini's avatar
      udp: fix buffer overflow in udp checksum · 94d709f8
      Alessandro Rubini authored
      This is my own fault introduced here:
      
         765443c7 udp: bugfix for checksum generation
      
      It made no harm, because all send frames were oversized, but I'm now
      using fixed-size buffers, and this overwrites the own IP address
      thus corrupting the checksum and so on.
      
      Pity me.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      94d709f8
    • Alessandro Rubini's avatar
      7167cb3f
  10. 20 Jun, 2017 2 commits
  11. 20 Mar, 2017 3 commits
  12. 28 Feb, 2017 3 commits
  13. 23 Feb, 2017 1 commit
  14. 16 Feb, 2017 4 commits
  15. 04 Aug, 2016 2 commits