On 28/05/2014 4:47 pm, Ralf Kirchner wrote:
-------- Original-Nachricht --------
Betreff: Re: [PATCH 09/12] fsdosfssync01: Stack size for bdbuf SMP
workaround
Datum: Tue, 27 May 2014 17:11:32 +0200
Von: Ralf Kirchner <ralf.kirch...@embedded-brains.de>
Organisation: embedded-brains GmbH
An: Gedare Bloom <ged...@rtems.org>
Am 27.05.2014 17:04, schrieb Gedare Bloom:
On Tue, May 27, 2014 at 10:47 AM, Ralf Kirchner
<ralf.kirch...@embedded-brains.de> wrote:
Increase the size of the init task stack for the SMP workaround within bdbuf.
---
testsuites/fstests/fsdosfssync01/init.c | 12 ++++++++++++
1 Datei geändert, 12 Zeilen hinzugefügt(+)
diff --git a/testsuites/fstests/fsdosfssync01/init.c
b/testsuites/fstests/fsdosfssync01/init.c
index b0022e9..022cd2b 100644
--- a/testsuites/fstests/fsdosfssync01/init.c
+++ b/testsuites/fstests/fsdosfssync01/init.c
@@ -170,6 +170,18 @@ size_t rtems_ramdisk_configuration_size = 1;
#define CONFIGURE_EXTRA_TASK_STACKS (8 * 1024)
+
+#if defined( RTEMS_SMP )
+ #if defined( RTEMS_POSIX_API )
+ /* The single core bdbuf implementation with enabling and disabling
preemption
+ * will not work under SMP. Thus we need to use POSIX mutexes and POSIX
+ * condition variables as a workaround.
+ * These require additional stack size.
+ */
+ #define CONFIGURE_INIT_TASK_STACK_SIZE (2 * CPU_STACK_MINIMUM_SIZE)
+ #endif /* defined( RTEMS_POSIX_API ) */
+#endif /* defined( RTEMS_SMP ) */
+
This kind of hack in the application configuration is not very
user-friendly. You should adjust for the required resources in
confdefs.h instead, by configuring for the required mutexes/condvars
explicitly.
Hi Gedare,
That is beeing done. Memory for the mutexes and condition variables gets
allocated in confdefs.h.
Here I need more stack (likely because the nesting depth is higher for
mutexes and condition variables than for the single core handling with
semaphores).
And I need this addition stack only for this single test. All other
tests still had sufficient spare stack.
How many bsps and different architectures were tested ?
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
