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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED] 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
[email protected]
https://mail.gna.org/listinfo/adeos-main
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
--
Philippe.
