Re: [ECOS] follow up on UITRON wierdness..

[Hugo Tyson <hmt at redhat dot com>]

"Dave Airlie" <airlied@parthus.com> writes:
> For my uitron tasks I had
> 
>  user_value \
> "CYG_UIT_TASK( \"t1\", 1, dtask1, &stack1, CYGNUM_UITRON_STACK_SIZE ), \\
>       CYG_UIT_TASK( \"t2\", 1, dtask2, &stack2, CYGNUM_UITRON_STACK_SIZE
> ), \\
>       CYG_UIT_TASK( \"t3\", 1, dtask3, &stack3, CYGNUM_UITRON_STACK_SIZE
> ), \\
>       CYG_UIT_TASK( \"t4\", 1, dtask4, &stack4, CYGNUM_UITRON_STACK_SIZE
> ), \\
>       CYG_UIT_TASK( \"t5\", 1, dtask5, &stack5, CYGNUM_UITRON_STACK_SIZE
> ),"
> 
> 
> All priority level 1... all tasks are equal ... with this is messes up ..
> 
> chaning the pri levels to 1,2,3,4,5 works fine ..
> 
> someone from RH want to tell me why? it doesn't seem to be mentioned
> anywhere ...

Sorry, I don't know.  I (with my Mister uITRON hat on) did take a look at
this, and I did note the article for later attention, so don't feel
ignored/unloved, please ;-)
 
> what wierder is with asserts turned off the code still runs fine ...

> (waiting for someone to point out a really obvious comment)

I don't have one, sorry. ;-(

I have a coupla thoughts:

The difference between running all the same prio and with prios 1-5 is:
 o Same: tasks will be swapped by interrupts, by timeslicing
 o Diff: tasks will only swap cooperatively, by function calls that wait

these would likely be at different depths of stack call; that would explain
different behaviour if the stacks were overlapping (or plain too small - I
trust you checked for *that*)

What's your declaration of the stacks?  Are they accidentally overlapping?
Are they actually CYGNUM_UITRON_STACK_SIZE bytes in size?

You can write CYG_UIT_TASK( \"t5\", 1, dtask5, &stack5, sizeof(stack5) ) in
there instead if you want, you understand this ugly macro is just an array
initializer with macros in?

Beware, we once for quite a long time had an hilarious bug where the stack
base and size args of thread initialization were swapped.  This didn't
matter at all, and wasn't detected, because the kernel starts using store
at (base + size) ie. the top of the stack; which is the same as (size +
base).  But it meant that stack limit asserts were all bogus.

My point is, it's easy for things like that to be badly wrong and have the
system mostly work!

Have you added any trick interrupt handler and device of your own?  Are you
perhaps getting a recursive interrupt chewing up the stack?  (or should
that be <verb>ing down the stack ;-) )

HTH, sorry I can't see anything obvious,

	- Huge