On 03/02/16 09:16, Darshit Shah wrote:
Breakpoint 1, _Thread_Set_state (the_thread=0x21a3e0, state=262144) at
>rtems-4.12/c/src/../../cpukit/score/src/threadsetstate.c:39
>39 _Scheduler_Acquire( the_thread, &lock_context );
>(gdb) bt
>#0 _Thread_Set_state (the_thread=0x21a3e0, state=262144) at
>rtems-4.12/c/src/../../cpukit/score/src/threadsetstate.c:39
>#1 0x0010c43e in _Event_Seize (event_in=2147483648, option_set=0, ticks=0,
>event_out=0x24f96c, executing=0x21a3e0, event=0x21a5f8, wait_class=512,
>block_state=262144, lock_context=0x24f944)
> at rtems-4.12/c/src/../../cpukit/rtems/src/eventseize.c:101
>#2 0x0010f080 in rtems_event_system_receive (event_in=2147483648,
>option_set=0, ticks=0, event_out=0x24f96c) at
>rtems-4.12/c/src/../../cpukit/rtems/src/systemeventreceive.c:52
>#3 0x00100b58 in rtems_event_transient_receive (option_set=0, ticks=0) at
>../../../../../realview_pbx_a9_qemu_smp/lib/include/rtems/rtems/event.h:484
>#4 0x00101568 in test () at
>rtems-4.12/c/src/../../testsuites/smptests/smpload01/init.c:333
>#5 0x0010177a in Init (arg=2150284) at
>rtems-4.12/c/src/../../testsuites/smptests/smpload01/init.c:384
>#6 0x00118efa in _Thread_Entry_adaptor_numeric (executing=0x21a3e0) at
>rtems-4.12/c/src/../../cpukit/score/src/threadentryadaptornumeric.c:25
>#7 0x00121524 in _Thread_Handler () at
>rtems-4.12/c/src/../../cpukit/score/src/threadhandler.c:93
>#8 0x001214ce in _User_extensions_Thread_exitted (executing=0x1214cf
><_Thread_Handler>) at
>../../cpukit/../../../realview_pbx_a9_qemu_smp/lib/include/rtems/score/userextimpl.h:244
>#9 0x00001008 in ?? ()
>Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>(gdb)
>
>If you are not familiar with the command line GDB, then I recommend to do a
>GDB tutorial first.
>
Now stepping through the scheduler. Will spend some time looking into
this and the source directly to see what I am able to gather.
We use a lot of inline functions via function pointers in this area, so
stepping through is not easy. However, you see the relevant code parts.
The scheduler is currently a bit more complicated due to the scheduler
helping protocol. This will hopefully change with the OMIP implementation.
--
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
