1. 10 May, 2022 2 commits
  2. 22 Feb, 2022 1 commit
    • Omar Gabella's avatar
      KM3NET BROADCAST : - locking_enable in wr_link_on -> After unplug/plug or… · 2d3f7618
      Omar Gabella authored
      KM3NET BROADCAST : - locking_enable in wr_link_on -> After unplug/plug or disable/enable the WR master port, the CLB stay locked in Uninitialized servo state because the spll stays locked.
      		   - New WR state WRS_BROADCAST -> added for km3net monitoring via net.wr_st_gen variable.
      		   - wr_servo_reset if errcount > 5 -> to play in a safe way.
      2d3f7618
  3. 09 Feb, 2022 1 commit
  4. 08 Feb, 2022 1 commit
  5. 27 Dec, 2021 1 commit
  6. 22 Dec, 2021 1 commit
  7. 20 Dec, 2021 1 commit
  8. 07 Apr, 2021 3 commits
  9. 26 Feb, 2021 1 commit
  10. 22 Feb, 2021 2 commits
  11. 04 Dec, 2020 5 commits
  12. 02 Aug, 2018 2 commits
  13. 04 Sep, 2017 1 commit
  14. 07 Aug, 2017 1 commit
  15. 01 Aug, 2017 2 commits
  16. 31 Jul, 2017 1 commit
  17. 06 Jul, 2017 1 commit
  18. 03 Jul, 2017 1 commit
  19. 29 Jun, 2017 2 commits
  20. 23 Jun, 2017 3 commits
  21. 12 Jun, 2017 3 commits
    • Alessandro Rubini's avatar
      pdelay: rework and extend prev commit · 31f08f19
      Alessandro Rubini authored
      The previous commit is not enough as a fix.  This may happen:
      
          - we invalidate stamps after processing them
          - we send request
          - get reply, loose reply-fup
          - send request
          - loose reply, get f-up
      
      So we now invalidate when sending the request. And invalidate t4 alone
      as the beautifulness and symmetry of the previous commit is lost
      anyways.
      
      Note: there no need to invalidate stamps in e2e mode, because checking
      the sequence number to validate RX frames is enough.  But here all
      replies match the sequence number, so the problem is not caught and
      stamps from different tuples are mixed.
      
      Example beofre this commit, with trimmed stamps (was 1497283863):
      
         diag-frames-1-wr1: SENT 54 bytes at 863.333173928 (pdelay_req)
         diag-frames-1-wr1: RECV 54 bytes at 863.334158796 (type 3, pdelay_resp)
         diag-frames-1-wr1: Drop received frame
         diag-frames-1-wr1: SENT 54 bytes at 864.479336104 (pdelay_req)
         diag-frames-1-wr1: Drop received frame
         diag-frames-1-wr1: RECV 54 bytes at 864.481095164 (type a, presp_follow_up)
      
         diag-servo-2-wr1: servo:t3 = 864:479336104:0
         diag-servo-2-wr1: servo:t4 = 863:333174267:586
         diag-servo-2-wr1: servo:t5 = 864:480295312:0
         diag-servo-2-wr1: servo:t6 = 863:334158796:773
         diag-servo-2-wr1: ->mdelay = -2:-292298352:359
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      31f08f19
    • Alessandro Rubini's avatar
      pdelay: mark stamps as invalid after use · 223459dd
      Alessandro Rubini authored
      The code is checking the sequence number of pdelay-rep and
      pdelay-rep-fup, but we may miss the reply and get the f-up.
      
      The result was something like this (first tuple is ok, next is wrong):
      
         diag-servo-2-wr1: servo:t3 = 1497279009:22584224:0
         diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
         diag-servo-2-wr1: servo:t5 = 1497279009:23564032:0
         diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
         diag-servo-2-wr1: ->mdelay = 0:684:306
      
         diag-servo-2-wr1: servo:t3 = 1497279009:663586672:0
         diag-servo-2-wr1: servo:t4 = 1497279009:22584574:759
         diag-servo-2-wr1: servo:t5 = 1497279009:683142000:0
         diag-servo-2-wr1: servo:t6 = 1497279009:23564365:547
         diag-servo-2-wr1: ->mdelay = -1:-300579732:306
      
      Here, t4 and t6 are old. The former is the receipt of the request,
      send back to the "slave" in the pdelay-reply payload; the latter is
      the receive time of such frame.
      
      We now invalidate t4 and t5 when using the tuple. They are the two
      "remote" times, one sent back in the response and the other sent back
      in the response-fup.
      Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
      223459dd
    • Alessandro Rubini's avatar
      dfeb1890
  22. 06 Apr, 2017 2 commits
  23. 05 Apr, 2017 2 commits