[RTEMS Project] #2148: Blackfin doesn't switch tasks, resets dispatch_necessary before querying it

[RTEMS trac]

#2148: Blackfin doesn't switch tasks, resets dispatch_necessary before querying it
----------------------+----------------------------
 Reporter:  rtemsdev  |       Owner:  joel.sherrill
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:  4.11
Component:  cpukit    |     Version:  HEAD
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+----------------------------

Old description:

> Problem xperienced with bf537Stamp BSP on real hardware (a board with
> ADSP-BF537 and just SDRAM and flash attached, only PLL, SDRAM, and UART
> are initialized):
>
> The ticker sample starts its three tasks, but all stall forever in
> rtems_task_wake_after(x) for any x greater than 1. Only the Idle task
> runs.
>
> The clockISR and rtems_clock_tick are executed and clock count is
> incremented.
>
> Debugging via JTAG with breakpoint at _Thread_Delay_ends made me discover
> that:
>
>  1. _Thread_Dispatch_necessary = true is set by
> _Scheduler_priority_unblock
>
>  2. Then it is cleared in cpukit/score/cpu/bfin/cpu_asm.S:480
> (doDispatch) by writing 0 to DISPATCH_NEEDED
>
>  3. Finally _Thread_Dispatch, called by _ISR15_Handler, doesn't do any
> Context_Switch because per_cpu->dispatch_necessary (the very same byte)
> is zero.
>
> As a workaround, removing the two lines after doDispatch in cpu_asm.S
> leads to a running ticker sample.
>
> doDispatch:
>   /* r0 = 0: */
>   /* B[p0] = r0; */
>   raise 15;
>
> I have not tried other tests yet. I suspect some more inconsistencies.
> This doesn't appear like it ever worked...?
>
> Also see discussion here:
> http://www.rtems.org/pipermail/rtems-users/2013-October/012038.html
>
> Another occurence with similar outcome, maybe for the same reason:
> http://www.rtems.org/pipermail/rtems-users/2013-May/011544.html
>
> Probably in RTEMS since 2008, with background e.g. discussed here:
> http://www.rtems.org/pipermail/rtems-users/2008-April/003129.html

New description:

 Problem xperienced with bf537Stamp BSP on real hardware (a board with
 ADSP-BF537 and just SDRAM and flash attached, only PLL, SDRAM, and UART
 are initialized):

 The ticker sample starts its three tasks, but all stall forever in
 rtems_task_wake_after(x) for any x greater than 1. Only the Idle task
 runs.

 The clockISR and rtems_clock_tick are executed and clock count is
 incremented.

 Debugging via JTAG with breakpoint at _Thread_Delay_ends made me discover
 that:

  1. _Thread_Dispatch_necessary = true is set by
 _Scheduler_priority_unblock

  2. Then it is cleared in cpukit/score/cpu/bfin/cpu_asm.S:480 (doDispatch)
 by writing 0 to DISPATCH_NEEDED

  3. Finally _Thread_Dispatch, called by _ISR15_Handler, doesn't do any
 Context_Switch because per_cpu->dispatch_necessary (the very same byte) is
 zero.

 As a workaround, removing the two lines after doDispatch in cpu_asm.S
 leads to a running ticker sample.

 doDispatch:
   /* r0 = 0: */
   /* B[p0] = r0; */
   raise 15;

 I have not tried other tests yet. I suspect some more inconsistencies.
 This doesn't appear like it ever worked...?

 Also see discussion here:
 http://www.rtems.org/pipermail/rtems-users/2013-October/012038.html

 Another occurence with similar outcome, maybe for the same reason:
 http://www.rtems.org/pipermail/rtems-users/2013-May/011544.html

 Probably in RTEMS since 2008, with background e.g. discussed here:
 http://www.rtems.org/pipermail/rtems-users/2008-April/003129.html

--

Comment (by joel.sherrill):

 I have no recollection of a patch being submitted. Does anyone else?

 Also the URLs for mail point to the old mhonarc archives so I am having
 trouble finding what they are talking about.

--
Ticket URL: <http://devel.rtems.org/ticket/2148#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project