I've recently purchased an Acorp i815ep, dual proc motherboard. Intel has
stated that the i815 will not work for a dual proc configuration, but
apparently Acorp has made it work :-)
I swapped out a single processor i815 motherboard, and installed the Acorp
motherboard with dual 1 Gig Pentium III processors. I booted up and
nearly immediately started seeing:
APIC error on CPU0: 00(08)
And similar messages. Though the computer continued booting, within a few
minuted I had received close to 400 of those messages, and then my
computer locked up.
Now, I can boot with the "noapic" option and that seems to solve the
problems. However, this situation is less than ideal, and I'd rather get
it working with APIC.
My first question: Is the lockup probably related to the error messaages?
Everything had been running smoothly on the single proc motherboard, and I
wasn't doing anything special when it locked up (I had launced galeon a
few seconds before and was typing into the google search screen).
My second question: Is there any chance of getting this working with
APIC, if not in 2.4.* maybe in a future release?
Adam
> APIC error on CPU0: 00(08)
discussed in the kernel faq.
> My second question: Is there any chance of getting this working with
> APIC, if not in 2.4.* maybe in a future release?
given that it's a hardware problem, no. but it *would* be cool
if the kernel noticed repeated APIC warnings and just turned
off apic use (as if you had booted with noapic). I'm guessing
this would be ugly, since APIC setup is probably discarded after boot...
>> My second question: Is there any chance of getting this working with
>> APIC, if not in 2.4.* maybe in a future release?
>
> given that it's a hardware problem, no. but it *would* be cool
> if the kernel noticed repeated APIC warnings and just turned
> off apic use (as if you had booted with noapic). I'm guessing
> this would be ugly, since APIC setup is probably discarded after boot...
There were some patches floating around to do exactly this (don't
remember where, sorry ;-) )
There's also an esr_disable flag variable I put in a while back
when doing bringup of NUMA-Q to smack the ESR into submission.
You might want to try tweaking that on in smp.h. It's not like we
actually do anything with the errors anyway. (all assuming my
mind isn't faulty, and this is actually the same thing). The read /
write protocol for ESR is really .... wierd, and it seems to need
smacking multiple times to accept a write.
M.
On Mon, 11 Mar 2002, Martin J. Bligh wrote:
> There's also an esr_disable flag variable I put in a while back
> when doing bringup of NUMA-Q to smack the ESR into submission.
> You might want to try tweaking that on in smp.h. It's not like we
> actually do anything with the errors anyway. (all assuming my
> mind isn't faulty, and this is actually the same thing). The read /
> write protocol for ESR is really .... wierd, and it seems to need
> smacking multiple times to accept a write.
We noticed that ;)
void __init setup_local_APIC (void)
{
unsigned long value, ver, maxlvt;
/* Pound the ESR really hard over the head with a big hammer - mbligh */
if (esr_disable) {
apic_write(APIC_ESR, 0);
apic_write(APIC_ESR, 0);
apic_write(APIC_ESR, 0);
apic_write(APIC_ESR, 0);
}
Cheers,
Zwane