Re: IO APIC error

[Andi Kleen]

"Kosta Porotchkin" <[e-mail]> writes:

>1. For some reason the "dmesg" is not displaying an early kernel messages.
>The log started somewhere from CPU #2 initialization (which is third CPU -
>Two Xeons are recognized as four processors, it is normal). I stopped this
>kernel in debugger and got some messages from MP table parsing procedure
>which were not included in "dmesg" output:

Increase the buffer in kernel/printk.c

>3. The things are going wrong during the test phase (i.e. after the "testing
>the IO APIC....................." is printed). IO APIC #2 register #00 reads
>02008000, which is wrong according to the chipset specification - should be
>02000000. That is the reason I got the warning "unexpected IO-APIC, please
>mail to [e-mail]". Let's said that the platform I using is
>pretty new and some hardware errors may happen, so I am less worry about
>this particular message. The most strange thing is the readings from the
>rest of IO APICs. The IO APIC #3 reads physical ID 4, #4 also 4, both # 5
>and #8 has 08000000 in their register #00. How it can be?

It's possible that the mptable is wrong. Windows uses ACPI to find
the IO-APIC, so the mptable is often not well tested. It may help
to change the MP support in the BIOS setup from 1.4 to 1.1.

> 4. When I tried to understand the source code, I found that all the IO APIC
> operations are done trough the fixed memory addresses (io_apic_read() and
> io_apic_write() in io_apic.h). I am sure, I do not understand the boot
> process enough for asking my questions, but probably someone from Linux
> community will help me to solve this problem. Why the fixed addresses are
> used? Shouldn't we use the base address provided by BIOS in MP table for
> each IO APIC?

The MP table contains physical addresses. Linux kernel uses virtual 
addresses. The physical addresses are mapped to the fixed virtual
addresses in init_apic_mappings(). 

-Andi