cdtest failure

Daron Chabot daron.chabot at usask.ca
Tue Apr 29 14:19:51 UTC 2008


On 28-Apr-08, at 2:16 PM, Daron Chabot wrote:

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


Joel,

I took some extra time to clean up cdtest (init.c was nearly  
useless). Please review the attached patch.

-- dc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cdtest-1.diff
Type: application/octet-stream
Size: 3574 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20080429/0545d665/attachment.obj>
-------------- next part --------------



More information about the users mailing list