ARM - after update from rtems4.9.3 to rtems-4.9.5 Unlimited Task Test fails

[Joel Sherrill]

On 03/01/2011 07:48 AM, Joachim Rahn wrote:
> Hi all,
>
> after updating from rtems-4.9.3 to rtems-4.9.5 the "Unlimited Task Test" on my
> ARM cpu at91sam9263 fails with a message like...
>
> [...skip...]
> task 19 ending.
> task 20 ending.
> task 21 ending.
> task 7 ending.
> task 8 ending.
>
> INSN_LDR
> data_abort at address 0x20018CD8, instruction: 0xE5932000,   spsr = 0x20000013
> active thread thread 0x0A010001
> Previous sp=0x200629A8 lr=0x200135E0 and actual cpsr=60000097
>   0x20038E30 0x20056EA8 0x0000117C 0x200629E0 0x200629C4 0x200135E0
>   0x20018CB8 0x20038E30 0x20056EA8 0x20026EC0 0x20026EC0 0x20062A18
>   0x200629E4 0x20010100 0x200135AC 0x00000000 0x00000000 0x00000000
>   0x00000000 0x20056EA8 0x20038E30 0x60000013 0x600000D3 0x00000000
>   0x00000000 0x20062A28 0x20062A1C 0x2000AE48 0x2000FFF8 0x20062A4C
>   0x20062A2C 0x2000ADA0 0x2000AE24 0x521C9845 0x20056EA8 0x00000000
>   0x00000000 0x2002ACD8 0x20062A64 0x20062A50 0x20000348 0x2000AD28
>   0x00000008 0x00000001 0x20062A84 0x20062A68 0x2001C2D4 0x20000310
>
> [...skip...]
>
> which commonly means the cpu tries to access non available memory.
>
> After removing the bugfix bug1718 the "Unlimited Task Test" works fine.
>
> (https://www.rtems.org/bugzilla/show_bug.cgi?id=1718)
>
> *** rtems-4.9.3: ./cpukit/sapi/include/confdefs.h *** unlimited task test works
> [...skip...]
>
>    #define CONFIGURE_MEMORY_PER_TASK_FOR_POSIX_API \
>      _Configure_From_workspace( \
>        sizeof (POSIX_API_Control) + \
>       (sizeof (void *) * (CONFIGURE_MAXIMUM_POSIX_KEYS)) \
>      )
>
> [...skip...]
>
> *** rtems-4.9.5: ./cpukit/sapi/include/confdefs.h *** unlimited task test doesn't work
> [...skip...]
>    #define CONFIGURE_MEMORY_PER_TASK_FOR_POSIX_API \
>      _Configure_From_workspace( \
>        CONFIGURE_MINIMUM_TASK_STACK_SIZE + \
>        sizeof (POSIX_API_Control) + \
>       (sizeof (void *) * (CONFIGURE_MAXIMUM_POSIX_KEYS)) \
>      )
> [...skip...]
>
> Any hints respectively does anyone observe the same?
>
That patch wouldn't directly cause that failure.
The only think I can see is that does change the
amount of workspace reserved up front (by a lot).

Is this a BSP which is in the RTEMS tree?  I am
suspicious that there isn't enough memory for
the workspace/heap and the BSP initialization
isn't recognizing this.  Eventually the task stacks,
heap, etc all collide, there is corruption and you crash.

So we would need to know the following:

+ address of end of BSS
+ start of memory for heap and length
+ start of memory for RTEMS workspace and length.
+ amount of RAM

Assuming that the workspace/heap are from end of
BSS to the end of RAM.
> Cheers
>
> --
> Joachim
>
> ________________________________
>
> Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
>
> Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V
>
> Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn- Rudolph
> Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer
>
> Sitz Berlin, AG Charlottenburg, 89 HRB 5583
>
> Postadresse:
> Hahn-Meitner-Platz 1
> D-14109 Berlin
>
> http://www.helmholtz-berlin.de
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


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