cdtest failure

[Joel Sherrill]

Daron Chabot wrote:
> Joel Sherrill wrote:
>   
>>> rying to run cdtest.exe (rtems cvs HEAD) in qemu (0.9.1) failed with
>>> the following output:
>>>
>>> djc at toolbox--
>>> <http://rtems.rtems.org/mailman/listinfo/rtems-users>> qemu
>>> -no-reboot -m 128 -boot n -tftp /opt/rtems/i386-
>>> rtems/pc386/lib/rtems-4.9/tests -bootp /cdtest.exe -serial stdio
>>> 2008-04-26 11:01:41.589 i386-softmmu[6716] KO
>>> rtems_gxx_mutex_init
>>> fatal error, exiting
>>>
>>> EXECUTIVE SHUTDOWN! Any key to reboot...2008-04-26 11:01:59.995 i386-
>>> softmmu[6716] KO
>>>
>>>
>>> Inserting some instrumentation in "libcsupport/src/gxx_wrappers.c"
>>> showed that the call to rtems_semaphore_create( ) was returning an
>>> rtems_status_code of 5==RTEMS_TOO_MANY.
>>>
>>> Changing CONFIGURE_MAXIMUM_SEMAPHORES from 1 to 2 in cdtest's
>>> "system.h" permits the test to run to a successful conclusion.
>>>
>>> Questions: "where is the other semaphore being consumed" ?? and
>>> "what  has changed to require more than a single semaphore" ??
>>>
>>>       
>> Breaking on rtems_semaphore_create will obviously
>> answer the question but I recall that g++ added
>> a second mutex in recent history.
>>
>> Can you double check where each create is called
>> from before we add one?  Just to make sure we are
>> not covering up a shortage somewhere.
>>
>> It may make sense to add a "C++ application" configuration
>> constant similar to the "NUMBER_OF_ADA_TASKS" one.  That
>> hides the ugly details of what C++ will actually use.
>>
>> I also distinctly recall adding a semaphore to the
>> configuration in my local tree but obviously I threw
>> that change away and didn't commit it. :(
>>
>> If you can explain this, it would really help.
>> I am teaching 4 days this week and doing prep work today.
>>     
>
> Solved: the mutex problem was of my own making :-(
>
> I forgot that lately I have been configuring RTEMS (pc386 BSP) with
> "USE_COM1_AS_CONSOLE=1". This configuration permits capture of RTEMS
> stdout to a scrollable terminal window in Qemu (with the -serial stdio
> command-line option), but it also must trigger the inclusion of an extra
> mutex (termios?) beyond that required by c++.
>
> Doh......
>
> Interestingly, using "objdump -S -D cdtest.exe" reveals calls to
> "rtems_semaphore_create( )" in the following:
> 1) rtems_gxx_mutex_init
> 2) rtems_libio_init
> 3) rtems_termios_open
>
> New question:
> Given that rtems_gxx_mutex_init( ) consumes the sole semaphore
> configured for the Workspace, why does printf(), used for
> instrumentation in cdtest.exe, NOT require configuration for another
> semaphore (i.e 2 in total)?
>   
This is why I like to have feature based configuration.
Some of the semaphores configured are because there
are termios devices. So you have the configuration macro
CONFIGURE_NUMBER_OF_TERMIOS_PORTS which makes
more sense than me asking you how many semaphores
do you need for one serial port.
> If I #define RTEMS_TEST_IO_STREAM in cdtest (to drag in cin/cout/cerr
> machinery) I have to change CONFIGURE_MAXIMUM_SEMAPHORES from 2 (with
> USE_COM1_AS_CONSOLE=1) to 5:
>
> Is that one mutex for gxx_mutex_init, one for termios, and three for
> cin/cout/cerr ??
>
>   
That sounds very likely.  Can you also change the test to
increase the configuration when you enable
RTEMS_TEST_IO_STREAM? 

confdefs.h is supposed to make it easier by asking higher
level questions like "number of FILE descriptors".  You
should not know how that is implemented and how many
resources are required per FILE descriptor.

But it is very easy to make a mistake and forget something
in confdefs.h.  Right now, confdefs.h is probably a bit too
conservative.  It seems more prone to slight overallocation
than underallocation.  Each time I find one of these places,
I push it down.   For example, all tasks are assumed to have
a floating point context.  We know that isn't always true. :-D
> -- dc
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985