_Internal_error_Occurred from rtems_semaphore_obtain in rtems_termios_write

[Kenneth J. Peters]

My error was coming from printing in an rtems_timer_fire_after() 
service routine. That used to work in 4.5.0, but now does not 
(probably for the best).

I see there is now rtems_timer_server_fire_after(), which in the 
online docs sounded like it would allow me to print, but in practice 
does not. I expect that's because the timer service task is created 
as RTEMS_NO_PREEMPT. So the task-based timers can do somewhat more 
than the regular timers, but not everything.

Is there an approved way to print from a timer service routine, or is 
that just bad? I can give up the printing if necessary; it's just a 
convenience.

Note that the online docs are wrong for the calling sequence

>rtems_status_code rtems_timer_initiate_server(
>    unsigned32           stack_size,
>    rtems_attribute      attribute_set
>)
>);

the actual sequence is

>rtems_status_code rtems_timer_initiate_server(

      unsigned32           priority,

>    unsigned32           stack_size,
>    rtems_attribute      attribute_set
>)
>);


and the timerserver.c code should use rtems_build_name() to avoid 
byte swapping on various CPUs:

>   /*
>    *  Create the Timer Server with the name the name of "TIME".  The attribute
>    *  RTEMS_SYSTEM_TASK allows us to set a priority to 0 which will makes it
>    *  higher than any other task in the system.  It can be viewed as a low
>    *  priority interrupt.  It is also always NO_PREEMPT so it looks like
>    *  an interrupt to other tasks.
>    *
>    *  We allow the user to override the default priority because the Timer
>    *  Server can invoke TSRs which must adhere to language run-time or
>    *  other library rules.  For example, if using a TSR written in Ada the
>    *  Server should run at the same priority as the priority Ada task.
>    *  Otherwise, the priority ceiling for the mutex used to protect the
>    *  GNAT run-time is violated.
>    */
>
>   status = rtems_task_create(

     rtems_build_name('T','I','M','E'), /* 0x4954454d,           /* "TIME" */

>     _priority,            /* create with priority 1 since 0 is illegal */
>     stack_size,           /* let user specify stack size */
>     RTEMS_NO_PREEMPT,     /* no preempt is like an interrupt */
>                           /* user may want floating point but we need */
>                           /*   system task specified for 0 priority */
>     attribute_set | RTEMS_SYSTEM_TASK,
>     &id                   /* get the id back */
>   );

I'll put in a PR with these minor things sometime soon.

Ken


At 1:58 PM -0700 8/30/06, Kenneth J. Peters wrote:
>Of course, as soon as I sent to the list, I found more info. I see 
>now that the magic "18" corresponds to RTEMS_CALLED_FROM_ISR from 
>cpukit/rtems/include/rtems/rtems/status.h
>and from doc/porting/interrupts.t I see that 
>_Thread_Dispatch_disable_level is basically saying I'm in a trap 
>somewhere.
>
>It still seems to me that _CORE_mutex_Seize should use a defined 
>value, either from the RTEMS status values or from the internal 
>errors list. Those two lists of values do not agree at all entries.
>
>Ken
>
>>I'm getting _Internal_error_Occurred called from 
>>rtems_semaphore_obtain in rtems_termios_write.
>>
>>Sparc erc32-based BSP on custom hardware.
>>
>>Two issues:
>>
>>1. The _Internal_error_Occurred call is actually in 
>>cpukit/score/include/rtems/score/coremutex.h
>>and is just called with a hardcoded number, not an 
>>Internal_errors_Core_list enum item from 
>>cpukit/score/include/rtems/score/interr.h
>>
>>>#define _CORE_mutex_Seize( \
>>>   _the_mutex, _id, _wait, _timeout, _level ) \
>>>   do { \
>>>     if ( _Thread_Dispatch_disable_level \
>>>         && (_wait) \
>>>         && (_System_state_Get() >= SYSTEM_STATE_BEGIN_MULTITASKING ) \
>>>        ) { \
>>>         _Internal_error_Occurred( \
>>>                             INTERNAL_ERROR_CORE, \
>>>                             FALSE, \
>>>                             18 /* called from wrong environment */); \
>>>     } \
>>
>>Seems like this error code should be in the 
>>Internal_errors_Core_list enum . I don't know if there are any 
>>other hardcoded error values elsewhere.
>>
>>2. I have not traced all through my code yet, or created a simple 
>>example. It could be that I am just doing something stupid like 
>>accidentally trying to print in a trap handler. However, if some 
>>kernel expert can explain a little about 
>>_Thread_Dispatch_disable_level, that might help me figure out 
>>what's going on. I am in multitasking when the error occurs, and 
>>the obtain call is with RTEMS_WAIT, so those make general sense to 
>>me.
>>
>>Ken Peters
>>Ken.Peters at jpl.nasa.gov