From: Philippe Gerum <rpm@xenomai.org>
To: Jim Cromie <jim.cromie@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] possible future conflict w LOCAL_APIC
Date: Sat, 30 Sep 2006 17:03:26 +0200 [thread overview]
Message-ID: <1159628606.5014.33.camel@domain.hid> (raw)
In-Reply-To: <451C586A.7020309@domain.hid>
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 x86-64.
> 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 breakage
> ratio vs saved code on disabled APIC code is definitely unbalanced.
>
> -Andi
>
>
>
> 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@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
next prev parent reply other threads:[~2006-09-30 15:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-28 23:19 [Xenomai-core] possible future conflict w LOCAL_APIC Jim Cromie
2006-09-29 11:12 ` Jan Kiszka
2006-09-30 15:03 ` Philippe Gerum [this message]
2006-10-03 17:52 ` Jim Cromie
2007-02-22 17:01 ` Jan Rüdiger
2007-02-22 17:12 ` Jan Kiszka
[not found] ` <45DDD478.7070403@domain.hid>
2007-02-23 8:33 ` [Xenomai-help] " Jan Kiszka
2007-02-23 8:46 ` Jan Rüdiger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1159628606.5014.33.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=jim.cromie@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.