freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] ipmiconsole on FreeBSD


From: Albert Chu
Subject: Re: [Freeipmi-devel] ipmiconsole on FreeBSD
Date: Thu, 24 Jun 2010 11:28:54 -0700

Hi Sean,

On Thu, 2010-06-24 at 09:59 -0700, Sean Bruno wrote:
> Just installed freeipmi via ports today (compiled on a FreeBSD 7 box)
> and when trying to invoke ipmiconsole was presented with the following
> error:
> 
> address@hidden ~]$ sudo /usr/local/sbin/ipmiconsole -h 10.73.149.134
> --debug
> (ipmiconsole_engine.c, ipmiconsole_engine_thread_create, 1121):
> pthread_mutex_unlock: Operation not permitted
> ipmiconsole_setup: Bad file descriptor
>
> Ick.  

Ick indeed.  Of all the porting issues I could have imaged, this would
have not been expected.  On Linux, the manpage shows

----
       The pthread_mutex_unlock() function may fail if:

       EPERM  The current thread does not own the mutex.
----

Some googling suggests its the same on FreeBSD.  From the line numbers,
it appears you're using a much older version of FreeIPMI.  The newest
version is 0.8.7, but you appear to be using something in the 0.7.X
timeframe.  Here's the code.

int
ipmiconsole_engine_thread_create(void)
{
  pthread_t thread;
  pthread_attr_t attr;
  unsigned int *index = NULL;
  int perr, rv = -1;

  assert(console_engine_is_setup);

  if ((perr = pthread_mutex_lock(&console_engine_thread_count_mutex)))
    {
      IPMICONSOLE_DEBUG(("pthread_mutex_lock: %s", strerror(perr)));
      errno = perr;
      return -1;
    }

  assert(console_engine_thread_count < IPMICONSOLE_THREAD_COUNT_MAX);

  if ((perr = pthread_mutex_unlock(&console_engine_thread_count_mutex)))
    {
      IPMICONSOLE_DEBUG(("pthread_mutex_unlock: %s", strerror(perr)));
      errno = perr;
      goto cleanup;
    }

  if ((perr = pthread_attr_init(&attr)))
    {
      IPMICONSOLE_DEBUG(("pthread_attr_init: %s", strerror(perr)));
      errno = perr;
      goto cleanup;
    }

  if ((perr = pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED)))
    {
      IPMICONSOLE_DEBUG(("pthread_attr_setdetachstate: %s", strerror(perr)));
      errno = perr;
      goto cleanup;
    }

  if (!(index = (unsigned int *)malloc(sizeof(unsigned int))))
    {
      IPMICONSOLE_DEBUG(("malloc: %s", strerror(errno)));
      goto cleanup;
    }
  *index = console_engine_thread_count;

  if ((perr = pthread_create(&thread, &attr, _ipmiconsole_engine, index)))
    {
      IPMICONSOLE_DEBUG(("pthread_create: %s", strerror(perr)));
      errno = perr;
      goto cleanup;
    }

  /* Who cares if this fails */
  if ((perr = pthread_attr_destroy(&attr)))
    IPMICONSOLE_DEBUG(("pthread_attr_destroy: %s", strerror(perr)));

  console_engine_thread_count++;

  rv = 0;
 cleanup:

  if ((perr = pthread_mutex_unlock(&console_engine_thread_count_mutex)))
    {
      IPMICONSOLE_DEBUG(("pthread_mutex_unlock: %s", strerror(perr)));
      errno = perr;
      return -1;
    }

  return rv;
}

I'm somewhat at a loss.  The lock up above clearly succeeded, so I'm not
sure how this error is happening.  Also, I know others have run this on
BSD without problems.

This is called via ipmiconsole_engine_init(), which isn't even at a
multi-threaded point. That begs the question, should I not even have the
mutexes there?  Maybe they're not necessary.  I actually see a few
points in the code maybe they could be removed.  Regardless, the error
shouldn't be happening.  Do you want to try and remove the lock and the
unlock in the above function
(ipmiconsole/src/libipmiconsole/ipmiconsole_engine.c) and see if that
fixes the problem?  PLMK if you'd like to try a patch.

I'm CCing Dmitry, FreeIPMI's resident BSD expert incase he knows
something I don't.  Perhaps there is something special about FreeBSD
pthreads that I don't know.

Al

> 
> Sean
> 
> 
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://*lists.gnu.org/mailman/listinfo/freeipmi-devel
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory




reply via email to

[Prev in Thread] Current Thread [Next in Thread]