Re: [Xenomai-core] possible future conflict w LOCAL_APIC

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]

Jim Cromie wrote:
> hi guys,
> 
> I encountered this error building 18-mm2 with a .config Ive been
> using with xenomai since I started. 
> 
>> arch/i386/kernel/built-in.o(.text+0x34f1): In function `do_nmi':
>> arch/i386/kernel/traps.c:752: undefined reference to
>> `panic_on_unrecovered_nmi'
>> arch/i386/kernel/built-in.o(.text+0x3564):arch/i386/kernel/traps.c:712:
>> undefined reference to `panic_on_unrecovered_nmi'
>>
>>
>> $ grep nmi arch/i386/kernel/Makefile
>> obj-$(CONFIG_X86_LOCAL_APIC)    += apic.o nmi.o
>>
>> which I dont have enabled.
> 
> 
> Will fix.
> 
> 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 ?
> 

At the bare minimum this would require to decouple the APIC vs. PIC
decision of I-pipe/Xenomai from Linux - or make it a runtime thing as well.

But given that upcoming clocksource/clockevent/genirq requires some
internal changes anyway (*), that aspect will only be a footnote in this
context. Maybe the result will mean one pitfall less for the poor
end-user... ;)

However, thanks for the hint.

Jan

(*) Also the main reason why there is no patch for 2.6.18 yet. Actually,
2.6.18 is terrible in this respect since it is only half way down the
path, even on x86. I'm convinced that in the end also I-pipe and Xenomai
will benefit from these arch-independent abstractions, e.g. by being
able to provide virtualised clocks or IRQ chips to Linux in a structured
way. But in the meantime it looks like we suffer.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]