[Adeos-main] ppc64 port questions

[Adeos-main] ppc64 port questions

[Reynolds, Terry (Contractor-SIMTECH)]

Hi All,
 
I apologize for the long posting, but wanted to give sufficient detail for folks to see what's going on.
 
I have made a good bit of progress on the ppc64 port.  I'm trying to get the RTAI example test latency to work.  
Things fail in a way that looks like I've missed a function somewhere.   I've added quite a few printk statements
in trying to track down the problem.
 
What I'm seeing is:
 
Root domain registered.
Pipeline started.
 
Start latency test:
 
RTAI[hal] domain registered:
   switch from root to RTAI[hal].
   calls suspend.
   switches back to root.
 
Domain IShield registered.
   root switches to IShield
  IShield suspends & switches back to root.
 
RTAI[nucleus] RTAI/fusion v0.6.9 started
  all initialization routines seem to run OK.
 __fusion_skin_init processes all the way through and exits without error.
 
THEN
 
In Root:
   sched.c's need_resched: calls -
   adeos_schedule_tail, which calls __adeos_handle_event with  ADEOS_SCHEDULE_TAIL
 
   __adeos_handle_event does a switch_to RTAI[hal] domain.
   it resumes in suspend_domain, from which it returns to rthal_domain_entry.
   At that point it is in a loop constantly calling suspend_domain.
   So, RTAI[hal] instantly suspends again, switching back to root. 
   Root ends up back in need_resced, and this process repeats several hundred times,
   until the latency test gives up and exits with a "failed to create display task, code -38"
 
IShield is unregistered.
RTAI/fusion stops.
RTAI is unregistered.
RTAI[hal] is unloaded.
 
At least things seem to exit gracefully!
 
So, my questions are:
 
  Did any of that description look totally wrong?  
 
   What is suppose to cause RTAI[hal] to break out of the suspend_domain loop,
  and process the event being passed in from root via the schedule_tail?  
  Should it be suspended at a different place?
 
I'm not sure if this is an Adeos or an RTAI problem at this point.
 
 
TIA!
 
Terry.
 
 
 

Re: [Adeos-main] ppc64 port questions

[Philippe Gerum]

Reynolds, Terry (Contractor-SIMTECH) wrote:
> Hi All,
>  
> I apologize for the long posting, but wanted to give sufficient detail for folks to see what's going on.
>  
> I have made a good bit of progress on the ppc64 port.  I'm trying to get the RTAI example test latency to work.  
> Things fail in a way that looks like I've missed a function somewhere.   I've added quite a few printk statements
> in trying to track down the problem.
>  
> What I'm seeing is:
>  
> Root domain registered.
> Pipeline started.
>  
> Start latency test:
>  
> RTAI[hal] domain registered:
>    switch from root to RTAI[hal].
>    calls suspend.
>    switches back to root.
>  
> Domain IShield registered.
>    root switches to IShield
>   IShield suspends & switches back to root.
>  
> RTAI[nucleus] RTAI/fusion v0.6.9 started
>   all initialization routines seem to run OK.
>  __fusion_skin_init processes all the way through and exits without error.
>  
> THEN
>  
> In Root:
>    sched.c's need_resched: calls -
>    adeos_schedule_tail, which calls __adeos_handle_event with  ADEOS_SCHEDULE_TAIL
>  
>    __adeos_handle_event does a switch_to RTAI[hal] domain.
>    it resumes in suspend_domain, from which it returns to rthal_domain_entry.
>    At that point it is in a loop constantly calling suspend_domain.
>    So, RTAI[hal] instantly suspends again, switching back to root. 
>    Root ends up back in need_resced, and this process repeats several hundred times,
>    until the latency test gives up and exits with a "failed to create display task, code -38"
>  
> IShield is unregistered.
> RTAI/fusion stops.
> RTAI is unregistered.
> RTAI[hal] is unloaded.
>  
> At least things seem to exit gracefully!
>  
> So, my questions are:
>  
>   Did any of that description look totally wrong?  
>

The behaviour described above looks sane.

>    What is suppose to cause RTAI[hal] to break out of the suspend_domain loop,
>   and process the event being passed in from root via the schedule_tail?  
>   Should it be suspended at a different place?
>  

adeos_suspend_domain() looks for events to process (traps & IRQs) before 
returning to the caller. So the proper callbacks for the current work 
cycle have already been fired when adeos_suspend_domain() returns back 
to the calling statement in the RTHAL entry point. This is why an Adeos 
work cycle usually looks like an endless loop calling 
adeos_suspend_domain().

> I'm not sure if this is an Adeos or an RTAI problem at this point.
>  

Everything looks ok so far.

>  
> TIA!
>  
> Terry.
>  
>  
>  
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 

Philippe.

Re: [Adeos-main] ppc64 port questions

[Philippe Gerum]

Reynolds, Terry (Contractor-SIMTECH) wrote:
> Hi All,
>  
> I apologize for the long posting, but wanted to give sufficient detail for folks to see what's going on.
>  
> I have made a good bit of progress on the ppc64 port.  I'm trying to get the RTAI example test latency to work.  
> Things fail in a way that looks like I've missed a function somewhere.   I've added quite a few printk statements
> in trying to track down the problem.
>  
> What I'm seeing is:
>  
> Root domain registered.
> Pipeline started.
>  
> Start latency test:
>  
> RTAI[hal] domain registered:
>    switch from root to RTAI[hal].
>    calls suspend.
>    switches back to root.
>  
> Domain IShield registered.
>    root switches to IShield
>   IShield suspends & switches back to root.
>  
> RTAI[nucleus] RTAI/fusion v0.6.9 started
>   all initialization routines seem to run OK.
>  __fusion_skin_init processes all the way through and exits without error.
>  
> THEN
>  
> In Root:
>    sched.c's need_resched: calls -
>    adeos_schedule_tail, which calls __adeos_handle_event with  ADEOS_SCHEDULE_TAIL
>  
>    __adeos_handle_event does a switch_to RTAI[hal] domain.
>    it resumes in suspend_domain, from which it returns to rthal_domain_entry.
>    At that point it is in a loop constantly calling suspend_domain.
>    So, RTAI[hal] instantly suspends again, switching back to root. 
>    Root ends up back in need_resced, and this process repeats several hundred times,
>    until the latency test gives up and exits with a "failed to create display task, code -38"

-ENOSYS. Either you did not properly implement the Linux syscall 
pipelining and RTAI requests end up being processed by the Linux kernel 
(instead of passing them first to the RTAI nucleus) -- which fails 
identifying the syscall number, or the RTAI nucleus rejected the call 
for some reason. Since you bring in a new Adeos port, you should make 
sure of that #1 works first.

>  
> IShield is unregistered.
> RTAI/fusion stops.
> RTAI is unregistered.
> RTAI[hal] is unloaded.
>  
> At least things seem to exit gracefully!
>  
> So, my questions are:
>  
>   Did any of that description look totally wrong?  
>  
>    What is suppose to cause RTAI[hal] to break out of the suspend_domain loop,
>   and process the event being passed in from root via the schedule_tail?  
>   Should it be suspended at a different place?
>  
> I'm not sure if this is an Adeos or an RTAI problem at this point.
>  
>  
> TIA!
>  
> Terry.
>  
>  
>  
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 

Philippe.