cdtest failure

[Daron Chabot]

Joel Sherrill wrote:
> 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?

Will do... I'll post a patch tonight.

-- dc

> 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
>>   
>
>