Rosenow, Jim wrote: > Sorry for the missing history. > > I started with a vanilla 2.6.14-7 kernel from kernel.org, I patched it > with a Motorola patch to enable the features specific to the mvme5500. > I built under ELDK 4.0 and the kernel ran just fine. > > Next I retrieved xenomai-2.1.1 and followed the install instructions. > The adeos version adeos-ipipe-2.6.14-1.2.03.patch. This patch applied > and I rebuilt the kernel. I ran into a problem with xmon not compiling > so I removed that switch from the kernel hacking menu and it built fine. > > That brings us to now. > > In reference to your recommendation, can I simply disable ipipe and > leave xenomai enabled and expect the kernel to run? I thought there was > a pretty close coupling between the two.
No, you are right, this is not possible. I meant booting with both ipipe and xenomai disabled. Is your board able to boot without the Motorola patches? If yes, does the problem persist? BTW, did the ipipe patch apply cleanly on top of the Motorola patch or did you have to fix some hunks? @all: What will help to track this down are back-traces of the crash. Does the console contain a stack trace as well? If not, try using the ipipe-tracer (additional patch [1]) and put an ipipe_trace_panic_freeze() + ipipe_trace_panic_dump() before that BUG() (with the same condition, of course). Actually, this tool can report more than a stack trace. It records a full function call history and may reveal where the ipipe patch left the correct path. Jan PS: Just in case you thought about this, switching the ipipe patch to 1.3 may only hide the problem. The newer patches contain optimisations, not bug fixes of the 1.2 series. [1] http://download.gna.org/adeos/patches/v2.6/ppc/tracer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
