[Xenomai-core] possible future conflict w LOCAL_APIC

[Xenomai-core] possible future conflict w LOCAL_APIC

[Jim Cromie]

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 ?

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

[Jan Kiszka]

[-- 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 --]

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

[Philippe Gerum]

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.

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

[Jim Cromie]

Philippe Gerum wrote:
> 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.
>
>   

update:

Ingo Molnar has voiced strong preference that the config option remain,
citing 60kb growth in its removal.  So its probably safe for now ;-)

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

[Jan Rüdiger]

Hello

Few months ago there was a discussion about disabling local apic in the
kernel. The last point in this discussion was:

> update:
> 
> Ingo Molnar has voiced strong preference that the config option remain,
> citing 60kb growth in its removal.  So its probably safe for now ;-)

Now i have the problem that i cant disable the X86_UP_APIC anymore when
building the kernel 2.6.19. Normally this isn't a problem since it is
disabled during boot (my machine doesn't have APIC). But xenomai is
build with enabled APIC and thus refuses to run on the new kernel.

Is there a way to disable APIC during kernel build? or can i build
xenomai without APIC?

thanks allot in advance

jan rüdiger

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

[Jan Kiszka]

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

Jan Rüdiger wrote:
> Hello
> 
> Few months ago there was a discussion about disabling local apic in the
> kernel. The last point in this discussion was:
> 
>> update:
>>
>> Ingo Molnar has voiced strong preference that the config option remain,
>> citing 60kb growth in its removal.  So its probably safe for now ;-)
> 
> Now i have the problem that i cant disable the X86_UP_APIC anymore when
> building the kernel 2.6.19. Normally this isn't a problem since it is

???

There is no "select X86_UP_APIC" in kbuild that would make this mandatory.

> disabled during boot (my machine doesn't have APIC). But xenomai is
> build with enabled APIC and thus refuses to run on the new kernel.
> 
> Is there a way to disable APIC during kernel build? or can i build
> xenomai without APIC?

We are running Xenomai over 2.6.19 (and later) here, mostly on APIC-less
(or broken) boxes. There is no known issue.

I don't see why you shouldn't be able to switch "Local APIC support on
uniprocessors" off.

Jan


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

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

[Jan Kiszka]

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

Jan Rüdiger wrote:
> Jan Kiszka wrote:
>> Jan Rüdiger wrote:
>>> Hello
>>>
>>> Few months ago there was a discussion about disabling local apic in the
>>> kernel. The last point in this discussion was:
>>>
>>>> update:
>>>>
>>>> Ingo Molnar has voiced strong preference that the config option remain,
>>>> citing 60kb growth in its removal.  So its probably safe for now ;-)
>>> Now i have the problem that i cant disable the X86_UP_APIC anymore when
>>> building the kernel 2.6.19. Normally this isn't a problem since it is
>> ???
>>
>> There is no "select X86_UP_APIC" in kbuild that would make this mandatory.
> 
> Thanks for your fast reply. Actually the option X86_UP_APIC is missing
> when doing "make menuconfig" under "Processor type and Feature" and also
> in the .config file. Thats why i can't disable it.
> As far as i understood it, this option was taken away an replaced with
> the possibility to have noapic flag at boot time.
> With this, however, xenomai ist still build with APIC enabled and
> refuses to run.

Do you happen to have SMP on? It takes away the choice of UP_APIC,
because it assumes to find an APIC in any case.

> 
> My 2.6.19.2 kernel was downloaded from kernel.org. All i did was "make
> cloneconfig" and then enabling xenomai and a few other things
> (preemption etc.)

Unless you need it otherwise, CONFIG_PREEMPT is not required for good
Xenomai latencies.

Jan


PS: Please take care of CC, I re-added xenomai-help.


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

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

[Jan Rüdiger]

Hi

> 
> Do you happen to have SMP on? It takes away the choice of UP_APIC,
> because it assumes to find an APIC in any case.
> 
thx allot, SMP was enabled by default, disabling this and setting the
sub architecture from "default" to "PC-compatible" finally gives me the
choice to disable LOCAL_APIC.

> Unless you need it otherwise, CONFIG_PREEMPT is not required for good
> Xenomai latencies.
> 
> Jan
> 
> 
> PS: Please take care of CC, I re-added xenomai-help.
>