On 2014-02-21 13:44, Peter Dufault wrote:
On Feb 21, 2014, at 07:16 , Sebastian Huber<sebastian.hu...@embedded-brains.de> 
 wrote:

>>I forgot to ask the important question: What happens when you increase the 
number of tasks to e.g. 8?  SP02 still didn't run, when I broke in with the debugger 
it was always in the idle task.
>
>It is the same problem: blocking on output.  As a quick hack you can add
>
>CPU_CFLAGS += -DTESTS_USE_PRINTK
>
>to the *.cfg file of your BSP.
I don't understand.  I'd expect the test to run once there were enough tasks.  
It sounds like a real bug.

Yes, its a bug in the test if you ask me. A lot of tests assume that output is non-blocking. They use this to determine which task executes when and in which sequence.


You say that the PREEMPT task is blocking on "puts( "PREEMPT - rtems_task_delete - deleting 
self" );" and never gets to the rtems_task_delete() that follows that line, and I guess you're 
saying all the other tasks are also blocking on their respective "puts()" calls, and that's why 
nothing happens when I increase the number of tasks.

If you increase the task count, then only the first problem spot is skipped.


I assume the default termios mode for the interrupt driven console is line 
buffered.  Why isn't the output eventually finishing?  Why doesn't increasing 
the number of tasks to 8 let things run through?

You hit another bug in the test.

--
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.
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel

Reply via email to