<div dir="ltr"><div>Hi<br><br></div><div>After some debugging i've found that in some cases a task that calls rtems_task_wake_after() will cause the _Thread_Handler to think its returned. Has anyone observed this before ?<br>
<br></div><div>A simple case as shown bellow does NOT fail, but a more complex example with 30+ tasks, 40+ timers etc does seem to reproducibly fail.<br></div><div><br><br></div>----------- snip ------------<br><br><div>rtems_task test_wake_after(rtems_task_argument ignored)<br>
{<br> rtems_task_wake_after(10);<br>}<br><br>rtems_task Init( rtems_task_argument ignored )<br>{<br> rtems_status_code status;<br> rtems_id id;<br><br> status = rtems_task_create( "wake_after",<br> 23,<br>
1024,<br> RTEMS_DEFAULT_MODES,<br> RTEMS_FLOATING_POINT | RTEMS_DEFAULT_ATTRIBUTES,<br> &id<br> );<br><br> status = rtems_task_start(id, test_wake_after, NULL);<br><br> for (;;)<br>
{<br> }<br>}<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 28 March 2013 15:28, Matthew J Fletcher <span dir="ltr"><<a href="mailto:amimjf@gmail.com" target="_blank">amimjf@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks all for the suggestions.<br><br>Looking at the 'executing' structure in _Thread_Handler() i can see that the last task being executed was the rtems_bdbuf_swapout_task(), i dont see how this can return, the only chance out of this seems to be via rtems_fatal_error_occured() which in the rtl22xx_t BSP is implemented as..<br>
<br>void rtems_fatal_error_occurred(<br> uint32_t the_error<br>) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE; Thats just defined as __attribute__ ((noreturn));<br><br>The return argument is 0x814c9c50, return code 6 according to the 'executing' structure.<br>
<br>If i comment out the rtems_io_register_driver() / rtems_rfs_format() on the NV device the problem does not occur, i just switch between the idle task and one of my threads.<br><br>So it looks like rtems_bdbuf_swapout_task() is returning, can i help any more tracking things down ?<div class="HOEnZb">
<div class="h5"><br>
<br><br><br><br><div class="gmail_quote">On 28 March 2013 14:03, Joel Sherrill <span dir="ltr"><<a href="mailto:Joel.Sherrill@oarcorp.com" target="_blank">Joel.Sherrill@oarcorp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just to directly answer the question about the idle thread. It is perfectly normal to have a system where that is the only ready thread. Even ticker spends most of its execution time in this state.<br>
<br>
POSIX threads implicitly delete themselves when they return.<br>
<br>
It is a fatal error for Classic API tasks to do so.<br>
<br>
This is just one example of the differing philosophies behind the two APIs.<br>
<br>
--joel<br>
<br>
Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
<div><br>
<br>
On 03/28/2013 01:26 PM, Matthew J Fletcher wrote:<br>
> Hi,<br>
><br>
> I am getting the above and presume i've made a mistake in some part of my setup.<br>
><br>
> I know task switching works, i switch between the idle task and my Init() task<br>
> fine, this error seems to occur in the task switch that occurs after i<br>
> rtems_task_suspend() the Init() task. That in itself i guess is fine, most of<br>
> the examples do it.<br>
><br>
> Would the above happen if there were no ready to be scheduled tasks except the<br>
> idle task ?<br>
<br>
</div><div>The only internal error in _Thread_Handler() is INTERNAL_ERROR_THREAD_EXITTED.<br>
The classic API tasks must not return. You have to delete them, e.g. with<br>
rtems_task_delete(RTEMS_SELF);<br>
<br>
--<br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</div><div><div>_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><div class="HOEnZb"><div class="h5">-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div><br>regards</div><div>---</div><div>Matthew J Fletcher</div><br>
</div>