On Thu, 2006-09-28 at 17:19 -0600, Jim Cromie wrote:
> BTW I was planning to make LOCAL_APIC unconditional on i386 too like on
> There is basically no reason ever to disable it, and the bug work around
> for buggy BIOS one can be done at runtime. Overall the #ifdef / compile
> ratio vs saved code on disabled APIC code is definitely unbalanced.
> This looks like it may become a problem:
> Q: The kernel message log says:
> "Xenomai: Local APIC absent or disabled!
> Disable APIC support or pass "lapic" as bootparam."
> A: Xenomai sends this message if the kernel configuration Xenomai was
> compiled against enables the local APIC support
> (CONFIG_X86_LOCAL_APIC), but the processor status gathered at boot
> time by the kernel says that no local APIC support is available.
> There are two options for fixing this issue:
> o either your CPU really has _no_ local APIC hw, then you need to
> rebuild a kernel with LAPIC support disabled, before rebuilding
> Xenomai against the latter;
> Is this something fundamental or merely inconvenient ?
Inconvenient because this would require some surgery, and a bit less
efficient, since we would have to select the proper timing mode handlers
dynamically through function pointers, right in the hot path (e.g. PIT
programming in oneshot mode), not to speak of leaving dead code at
runtime. Fortunately, this would be made simpler by the
periodic-over-aperiodic mode emulation which is planned, since the
periodic hw management code would go away as a result of such change.
This said, the impact of forcing CONFIG_X86_LOCAL_APIC on would be
limited to a handful of files, Xenomai-wise. Adeos-wise, this would have
the same impact than for the rest of the x86 kernel code: less ifdefs,
more dead code at runtime.
> Xenomai-core mailing list
Xenomai-core mailing list