An error occurred fetching the project authors.
  1. 09 Oct, 2017 1 commit
  2. 06 Oct, 2017 1 commit
  3. 05 Oct, 2017 1 commit
  4. 03 Oct, 2017 2 commits
  5. 01 Oct, 2017 1 commit
  6. 29 Sep, 2017 2 commits
  7. 28 Sep, 2017 1 commit
  8. 27 Sep, 2017 1 commit
  9. 26 Sep, 2017 1 commit
  10. 25 Sep, 2017 1 commit
  11. 24 Sep, 2017 1 commit
  12. 22 Sep, 2017 2 commits
  13. 21 Sep, 2017 1 commit
  14. 20 Sep, 2017 1 commit
  15. 18 Aug, 2017 2 commits
  16. 17 Aug, 2017 1 commit
  17. 10 Aug, 2017 2 commits
  18. 28 Jul, 2017 1 commit
  19. 19 Jul, 2017 1 commit
  20. 17 Jul, 2017 2 commits
  21. 06 Jul, 2017 2 commits
  22. 29 Jun, 2017 1 commit
  23. 21 Jun, 2017 1 commit
  24. 04 Jun, 2017 1 commit
  25. 25 Apr, 2017 1 commit
  26. 17 Apr, 2017 1 commit
  27. 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
  28. 03 Apr, 2017 1 commit
  29. 28 Mar, 2017 2 commits
  30. 23 Mar, 2017 2 commits
    • 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
    • Cedric Roux's avatar
      minor fixes · 89f747a2
      Cedric Roux authored
      89f747a2
  31. 15 Mar, 2017 1 commit