Details

    • Type: Improvement Improvement
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 6.0.0
    • Component/s: Build
    • Labels:
      None
    • Environment:

      OpenBSD

      Description

      Add OpenBSD support.

      1. 0001-Add-OpenBSD-support.patch
        11 kB
        Piotr Sikora
      2. freebsd.patch
        0.5 kB
        Daniel Gruno

        Issue Links

          Activity

          Hide
          Piotr Sikora added a comment -

          Attached patch let's ATS & examples compile on OpenBSD, but this isn't usable state yet, because ATS fails to register kqueue events.

          I most likely won't have time to investigate this further during the next few weeks, so if anyone wants to take a shot at it, it would be great.

          Show
          Piotr Sikora added a comment - Attached patch let's ATS & examples compile on OpenBSD, but this isn't usable state yet, because ATS fails to register kqueue events. I most likely won't have time to investigate this further during the next few weeks, so if anyone wants to take a shot at it, it would be great.
          Hide
          Piotr Sikora added a comment -

          Uhm, like the original comment says, this one patch only lets ATS compile on OpenBSD.

          Know issues (so far):
          1) it goes straight away to 100% CPU doing gettimeofday() thousands of time per second.
          2) it crashes after first request when compiled without --enable-debug.
          3) it crashes right away when compiled with --enable-debug:

          FATAL: ../../lib/ts/ink_thread.h:267: failed assert `pthread_cond_wait(cp, mp) == 0`
          

          4) it fails to regiester kqueue events:

          ERROR: [iocore_dns] open_con: Failed to add 257175888 server to epoll list
          

          Those might be partly my fault, because I'm compiling it with:

          CXXFLAGS="-DRENTRENT_GETHOSTBYNAME -DRENTRENT_GETHOSTBYADDR"
          

          even though I know this isn't true, but OpenBSD doesn't have thread-safe gethostby

          {name,addr}

          () implementation... Ideally, we should use getaddrinfo() here.

          All in all, I'm not too happy about the "Resolved / Fixed" status update. Oh, and this patch got committed with wrong ticket number (TS-992 instead of TS-993).

          Show
          Piotr Sikora added a comment - Uhm, like the original comment says, this one patch only lets ATS compile on OpenBSD. Know issues (so far): 1) it goes straight away to 100% CPU doing gettimeofday() thousands of time per second. 2) it crashes after first request when compiled without --enable-debug. 3) it crashes right away when compiled with --enable-debug: FATAL: ../../lib/ts/ink_thread.h:267: failed assert `pthread_cond_wait(cp, mp) == 0` 4) it fails to regiester kqueue events: ERROR: [iocore_dns] open_con: Failed to add 257175888 server to epoll list Those might be partly my fault, because I'm compiling it with: CXXFLAGS= "-DRENTRENT_GETHOSTBYNAME -DRENTRENT_GETHOSTBYADDR" even though I know this isn't true, but OpenBSD doesn't have thread-safe gethostby {name,addr} () implementation... Ideally, we should use getaddrinfo() here. All in all, I'm not too happy about the "Resolved / Fixed" status update. Oh, and this patch got committed with wrong ticket number ( TS-992 instead of TS-993 ).
          Hide
          Leif Hedstrom added a comment -

          Moving out to v3.3.0, please move back if/when you have fixes for this.

          Show
          Leif Hedstrom added a comment - Moving out to v3.3.0, please move back if/when you have fixes for this.
          Hide
          Leif Hedstrom added a comment -

          Moved to 3.1.4, please move bugs back to 3.1.3, which you will work on in the next 2 weeks.

          Show
          Leif Hedstrom added a comment - Moved to 3.1.4, please move bugs back to 3.1.3, which you will work on in the next 2 weeks.
          Hide
          Leif Hedstrom added a comment -

          Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on soon. Also, take a look at what can be closed here please!

          Show
          Leif Hedstrom added a comment - Moving this out to 3.3.0, please move back to 3.1.4 if this will be worked on soon . Also, take a look at what can be closed here please!
          Hide
          Piotr Sikora added a comment -

          Hey Leif,
          unfortunately, work circumstances changed for me in the past few months and I won't be working on ATS in the foreseeable future... Someone should takeover this.

          Show
          Piotr Sikora added a comment - Hey Leif, unfortunately, work circumstances changed for me in the past few months and I won't be working on ATS in the foreseeable future... Someone should takeover this.
          Hide
          James Peach added a comment -

          Bryan and Piotr, can you sort out what remains to be done for OpenBSD support?

          Show
          James Peach added a comment - Bryan and Piotr, can you sort out what remains to be done for OpenBSD support?
          Hide
          Leif Hedstrom added a comment -

          Do we really need two bugs for this? We also have TS-1193. Can we mark one as duplicate, or at least change the subject title on one of them, if it really is a subtask?

          Show
          Leif Hedstrom added a comment - Do we really need two bugs for this? We also have TS-1193 . Can we mark one as duplicate, or at least change the subject title on one of them, if it really is a subtask?
          Hide
          Daniel Gruno added a comment -

          The same bug applies to FreeBSD, as reported at http://www.freebsd.org/cgi/query-pr.cgi?pr=170829
          Issues 1, 2 and 3 are related to a mutex not being locked/acquired (according to FreeBSD at least, I'll have to make sure) in Log.cc and subsequently being told to do an ink_cond_wait (which fails with EPERM and thus causes it to loop forever without waiting). I'm attaching a patch that fixes this issue.

          Show
          Daniel Gruno added a comment - The same bug applies to FreeBSD, as reported at http://www.freebsd.org/cgi/query-pr.cgi?pr=170829 Issues 1, 2 and 3 are related to a mutex not being locked/acquired (according to FreeBSD at least, I'll have to make sure) in Log.cc and subsequently being told to do an ink_cond_wait (which fails with EPERM and thus causes it to loop forever without waiting). I'm attaching a patch that fixes this issue.
          Hide
          Daniel Gruno added a comment -

          Patch that fixes the broken loop in Log.cc that makes ATS fail during debug mode and consume 100% cpu

          Show
          Daniel Gruno added a comment - Patch that fixes the broken loop in Log.cc that makes ATS fail during debug mode and consume 100% cpu
          Hide
          Igor Galić added a comment -

          Daniel Gruno, are you sure we want ink_mutex_acquire() here, not ink_mutex_try_acquire()
          ink_mutex_acquire() causes an abort().

          Show
          Igor Galić added a comment - Daniel Gruno , are you sure we want ink_mutex_acquire() here, not ink_mutex_try_acquire() ink_mutex_acquire() causes an abort() .
          Hide
          Daniel Gruno added a comment -

          ink_mutex_try_acquire would be just as peachy for me, and probably a safer bet.
          I did try using the 'try' version myself, and got the same good results (ie cpu not rising to 100%).

          Show
          Daniel Gruno added a comment - ink_mutex_try_acquire would be just as peachy for me, and probably a safer bet. I did try using the 'try' version myself, and got the same good results (ie cpu not rising to 100%).
          Hide
          Igor Galić added a comment -

          +1 from me, but maybe you can get John Plevyak, or someone else who has a clue about how our threading stuff works to comment on this

          Show
          Igor Galić added a comment - +1 from me, but maybe you can get John Plevyak , or someone else who has a clue about how our threading stuff works to comment on this
          Hide
          Daniel Gruno added a comment -

          Patch for issues 1 through 3 is in trunk, as per [8665bbb1e5f34e6de5d709b0314a8fcb1eefec8d]. Can you confirm whether this solves these issues for OpenBSD?

          Show
          Daniel Gruno added a comment - Patch for issues 1 through 3 is in trunk, as per [8665bbb1e5f34e6de5d709b0314a8fcb1eefec8d] . Can you confirm whether this solves these issues for OpenBSD?
          Hide
          Leif Hedstrom added a comment -

          Moving to 3.3.2.

          Show
          Leif Hedstrom added a comment - Moving to 3.3.2.
          Hide
          Leif Hedstrom added a comment -

          Moving all these out to 3.5.0 (aka next dev cycle).

          Show
          Leif Hedstrom added a comment - Moving all these out to 3.5.0 (aka next dev cycle).
          Show
          Leif Hedstrom added a comment - Moving to 5.0.0 as per https://cwiki.apache.org/confluence/display/TS/New+Release+Processes

            People

            • Assignee:
              Unassigned
              Reporter:
              Piotr Sikora
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development