_CORE_mutex_Seize

[Joel Sherrill]

Wendell Thompson wrote:
> 
> My application using code from the ppp example calls
> rtems_bsdnet_semaphore_obtain, which then calls _Core_mutex_Seize, which
> then goes directly into _CORE_mutex_Seize_interrupt_blocking. It then
> swaps tasks and never returns to that task.
> 
> Shouldn't _CORE_mutex_Seize go into _CORE_mutex_Seize_interrupt_trylock?

I think it does but it does since since _CORE_mutex_Seize is a macro you
might not be seing it.  This is _CORE_mutex_Seize:

#define _CORE_mutex_Seize( \
  _the_mutex, _id, _wait, _timeout, _level ) \
  do { \
    if ( _CORE_mutex_Seize_interrupt_trylock( _the_mutex, &_level ) ) { 
\
      if ( !_wait ) { \
        _ISR_Enable( _level ); \
        _Thread_Executing->Wait.return_code = \
          CORE_MUTEX_STATUS_UNSATISFIED_NOWAIT; \
      } else { \
        _Thread_queue_Enter_critical_section( &(_the_mutex)->Wait_queue
); \
        _Thread_Executing->Wait.queue = &(_the_mutex)->Wait_queue; \
        _Thread_Executing->Wait.id    = _id; \
        _Thread_Disable_dispatch(); \
        _ISR_Enable( _level ); \
       _CORE_mutex_Seize_interrupt_blocking( _the_mutex, _timeout ); \
      } \
    } \
  } while (0)

Has the network stack been initialized?  I can see where 
rtems_bsdnet_semaphore_obtain might act wrong otherwise since
the_networkSemaphore wouldn't be set.  But since this works
for Ethernet and is always initialized, I would be looking at
something on the ppp side not initialized.
-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985