Re: [Adeos-main] RE: ppc64 port questions

[Philippe Gerum <rpm@xenomai.org>]

Reynolds, Terry (Contractor-SIMTECH) wrote:
> Hello,
>  
> I'll see if I can figure out a way to get a complete listing off my G5.  It isn't connected to the network, 
> and I've never actually produced a readable cd from it.
>  
> Mine is failing while loading the rtai_native module.  It seems Ok right up through the end of the 
> fusion_skin_init (I.E. the end of module_init).  After that the kernel enters a loop apparently either trying
> to start a task, or responding to some periodic task that was started by the module.  If I run the latency 
> test, this loop terminates after several seconds, and all the rtai modules get un-loaded.  If I load the modules
> via insmod, the loop goes on forever.
>  
> I haven't tried the klatency test.  Cruncher crashed my G5 and corrupted the hard drive.  Luckily, a manual 
> fsck repaired it.  I haven't tried it again.
>  
> Does anyone have this stuff actually working on a PPC?  If so, could you share any helpful ideas as to 
> what is suppose to be happening after the rtai_native module is loaded?  I'm still trying to figure what
> is causing the kernel to be receive these events.
>

So far, RTAI/fusion (using Adeos patch 2.6.10rc3-r6c14 and above) is 
known to work on iBook2, Sandpoint and IceCube boards. Btw, RTAI lists
may be more appropriate for posting your latest questions.


> Thanks,
>  
>  
> Terry.
> 
> ________________________________
> 
> From: Heikki Lindholm [mailto:holindho@domain.hid]
> Sent: Thu 3/17/2005 11:34 PM
> To: Reynolds, Terry (Contractor-SIMTECH)
> Subject: Re: [Adeos-main] RE: ppc64 port questions
> 
> 
> 
> Hi,
> I'm trying to analyze a (probable) stack overflow problem with the ppc32
> version of adeos+fusion - it too dies at the latency test. Could you
> send me your heap of printk output (syslog, dmesg), so that I can get
> the general idea of the call chain - maybe these are related. Btw. How
> far do you get with klatency on the ppc64?
> 
> Regards,
>   Heikki Lindholm
> 
> Reynolds, Terry (Contractor-SIMTECH) kirjoitti:
> 
>>Hi All,
>>
>>
>>I have more info, but still no idea as to where things are broken.
>>
>>In trying to run the RTAI latency test, the program ends up in a loop processing schedule_tail
>>& schedule_head events until the test gives up.  Both events are "caught" in the
>>rtai/nucleus/shadow.c set of event handlers.  The _head event is caught from the handler
>>called in the _adeos_handle_events routine.  The _tail event is caught from the
>>_adeos_suspend_domain functions' event handler block.  The first is dispatched from
>>the root domain, whereas the second is from the RTAI domain.
>>
>>The schedule_tail event happens first.
>>
>>After several seconds of this loop, the latency test fails with a "failed to create display task, code -38". 
>>The rt_task_create function wasn't reached (the printk statement which is the first line doesn't get printed),
>>so this must be comming from one of the module_init functions.
>>
>>The shadow.c routines both report handling the events as the root domain.
>>
>>At the moment I'm stuck trying to figure out which routine is trying to spawn a task, and why it's failing.
>>
>>ANY help would be greatly appreciated!
>>
>>TIA.
>>
>>Terry
>>
>>________________________________
>>
>>From: adeos-main-admin@domain.hid on behalf of Reynolds, Terry (Contractor-SIMTECH)
>>Sent: Tue 3/15/2005 10:24 AM
>>To: adeos
>>Subject: [Adeos-main] ppc64 port questions
>>
>>
>>
>>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.
>>
>>
>>
>>
>>_______________________________________________
>>Adeos-main mailing list
>>Adeos-main@domain.hid
>>https://mail.gna.org/listinfo/adeos-main
>>
>>
>>
>>_______________________________________________
>>Adeos-main mailing list
>>Adeos-main@domain.hid
>>https://mail.gna.org/listinfo/adeos-main
> 
> 
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 

Philippe.