1. 19 Oct, 2017 1 commit
  2. 16 Oct, 2017 1 commit
  3. 09 Oct, 2017 1 commit
  4. 06 Oct, 2017 1 commit
  5. 05 Oct, 2017 1 commit
  6. 03 Oct, 2017 2 commits
  7. 01 Oct, 2017 1 commit
  8. 29 Sep, 2017 2 commits
  9. 28 Sep, 2017 1 commit
  10. 27 Sep, 2017 1 commit
  11. 26 Sep, 2017 1 commit
  12. 25 Sep, 2017 1 commit
  13. 24 Sep, 2017 1 commit
  14. 22 Sep, 2017 2 commits
  15. 21 Sep, 2017 1 commit
  16. 20 Sep, 2017 1 commit
  17. 18 Aug, 2017 2 commits
  18. 17 Aug, 2017 1 commit
  19. 10 Aug, 2017 2 commits
  20. 28 Jul, 2017 1 commit
  21. 19 Jul, 2017 1 commit
  22. 17 Jul, 2017 2 commits
  23. 06 Jul, 2017 2 commits
  24. 29 Jun, 2017 1 commit
  25. 21 Jun, 2017 1 commit
  26. 04 Jun, 2017 1 commit
  27. 25 Apr, 2017 1 commit
  28. 17 Apr, 2017 1 commit
  29. 10 Apr, 2017 1 commit
    • Cedric Roux's avatar
      integration fix: change the way to print the version · 10113a35
      Cedric Roux authored
      Using "system" to call "git log" is too error-prone.
      In the test setup, lte-softmodem was blocked because
      "git log" uses a pager ("less") and the pager was
      waiting for the user to press enter.
      
      We could pass "--no-pager" to "git log" but then
      what if someone runs the softmodem out of the source
      tree?
      
      cmake defines PACKAGE_VERSION, we can use that instead,
      as is done in openair-cn.
      10113a35
  30. 03 Apr, 2017 1 commit
  31. 28 Mar, 2017 2 commits
  32. 23 Mar, 2017 1 commit
    • Cedric Roux's avatar
      fix issue 227 - UE IP settings disrupts realtime · cff91499
      Cedric Roux authored
      see https://gitlab.eurecom.fr/oai/openairinterface5g/issues/227
      
      When the UE connects to the eNodeB and receives its IP address from the
      network, it calls system() to set it in the linux kernel world. This call
      is not done in a realtime thread, but in the NAS, which uses its own thread,
      independent of the realtime processing.
      
      In some situations this totally disrupts realtime processing.
      
      It is difficult to know precisely why that happens, but it seems that calling
      fork(), as system() does, in a multi-threaded program is not a good idea. (So
      say several people on the internet.) It is not clear why the softmodem is
      impacted, but it seems that fork() is really what triggers the disruption.
      Several tests lead to that conclusion.
      
      To fix the problem, we create a child background process very early in main()
      (before anything else basically). Then instead of calling system(), the main
      process sends the string to the background process. The background process
      gets the string, passes it to system() and reports the success/failure back
      to the main process.
      
      This solution involves a lot of system calls, but calling system() in the
      first place is not cheap either. As long as no realtime thread uses this
      mechanism, things should be fine. Time will tell.
      cff91499