This test fix is all right, but it is not clear why this worked before.
Something must have changed in RTEMS or the tool chain to trigger this
bug and this might be an additional problem or not.
On 15/04/15 21:21, Joel Sherrill wrote:
Abusing this topic more, this is the complete analysis. I missed the
final loop of create/delete queue. This is the comment in system.h
I have now.
/*
* Created in init.c:
* Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600)
* Q2 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) (160)
* Q3 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) (1600)
*
* Q1 and Q2 deleted in task1.c
*
* Q1 recreated in task1.c
* Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 ) (2000)
*
* Q1 deleted again in task1.c.
* Q1 repeatedly created and deleted for 2 messages of 1-1030 bytes
* in length
* Q1 - CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 ) (2000)
*
* Thus the peak message memory needed is technically only:
* Q3 + third instance of Q1 at peak of two 1030 byte messages.
*
*/
#define CONFIGURE_MESSAGE_BUFFER_MEMORY \
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 1030, 2 )
On 4/15/2015 1:30 PM, Joel Sherrill wrote:
On 4/15/2015 12:13 PM, Gedare Bloom wrote:
On Wed, Apr 15, 2015 at 2:49 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
Two message queues get deleted before the forth is created. Why did this
work before and what is the root cause for this failure? We will never know
after this patch.
Yes I don't understand what this is fixing. The test, or the failure?
Yes. The test under reserves. Here is a more detailed analysis:
For the purposes of this analysis, I am ignoring the overhead per
allocation.
Before the patch, the configuration was for the initial Q1-Q3 for 3360
bytes.
MESSAGE_SIZE is a constant in system.h and 16
NEED TOTAL AVAILABLE
0 3360
Q1 - 100 * MESSAGE_SIZE ==> 1600 1600 1760
Q2 - 10 * MESSAGE_SIZE ==> 160 1760 1600
Q3 - 100 * MESSAGE_SIZE ==> 1600 3360 0
delete Q1 1760 1600
delete Q2 1600 1760
Q1 - 100 * 20 ==> 2000
Since the second instance of Q1 needs more than the first instance,
it fails.
Current patch technically over reserves.
Since second instance of Q1 needs more than the first instance,
we could get by with Q1 second instance, Q2, and Q3 as the
reservation.
Obviously this would need a comment.
Do you want me to change it that way?
On 14/04/15 21:08, Joel Sherril wrote:
Module: rtems
Branch: master
Commit: 351858d75327d5bbda7e720157dced706bbe5688
Changeset:
http://git.rtems.org/rtems/commit/?id=351858d75327d5bbda7e720157dced706bbe5688
Author: Joel Sherrill <joel.sherr...@oarcorp.com>
Date: Tue Apr 14 14:07:35 2015 -0500
sp13: Update configuration to account for messages on fourth message queue
---
testsuites/sptests/sp13/system.h | 6 +++++-
testsuites/sptests/sp13/task1.c | 1 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/testsuites/sptests/sp13/system.h
b/testsuites/sptests/sp13/system.h
index 7bb680c..3b170bf 100644
--- a/testsuites/sptests/sp13/system.h
+++ b/testsuites/sptests/sp13/system.h
@@ -65,10 +65,14 @@ TEST_EXTERN rtems_name Queue_name[ 4 ]; /* array
of queue names */
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
+/*
+ * First three created in init.c, last created in task1.c.
+ */
#define CONFIGURE_MESSAGE_BUFFER_MEMORY \
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 10, MESSAGE_SIZE ) + \
- CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE )
+ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, MESSAGE_SIZE ) + \
+ CONFIGURE_MESSAGE_BUFFERS_FOR_QUEUE( 100, 20 )
#define CONFIGURE_EXTRA_TASK_STACKS (3 *
RTEMS_MINIMUM_STACK_SIZE)
diff --git a/testsuites/sptests/sp13/task1.c
b/testsuites/sptests/sp13/task1.c
index e783e37..e104e8d 100644
--- a/testsuites/sptests/sp13/task1.c
+++ b/testsuites/sptests/sp13/task1.c
@@ -267,6 +267,7 @@ rtems_test_pause();
&Queue_id[ 1 ]
);
directive_failed( status, "rtems_message_queue_create of Q1; 20 bytes
each" );
+
status = rtems_message_queue_send( Queue_id[ 1 ], big_send_buffer, 40
);
fatal_directive_status(status,
RTEMS_INVALID_SIZE,
_______________________________________________
vc mailing list
v...@rtems.org
http://lists.rtems.org/mailman/listinfo/vc
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
