Sander Smeenk (CistroN Medewerker) wrote:
> We've all seen this warning before I think? APIC error on CPU1: 08(08)
>
> Well I'm 101% sure it's memory related...
> Before I went to my parents for Christmas, I installed 2 different
> memory modules on my board (with a load of troubles, see my earlier
> messages about the beeeeep, beep, beep, beep sequence :]).
> I left my machine on as usual, so I could get in remote and do some
> work when I wanted to.
>
> Then I noticed this:
>
> [14:20] [ssmeenk@knopje:~] % dmesg | grep APIC | wc -l
> 546
>
> And this *NEVER EVER* happened with my old memory modules installed :]
> (Those are 'Brand' modules, the ones I have now are VM (Never heard of)).
This is a very interesting observation. Especially if both
your new and old memory is nominally good (passes memtest-86
and my burnBX and burnMMX utils).
The strange thing is there is no logical reason for the quality
of memory to induce APIC errors. The CPU APICs and the IO-APIC
communicate by a totally separate two-wire "bus" that runs at
BCLK/4 (17 MHz for a stock 66 MHz). The busses even run in
different directions: The APIC bus runs from one CPU to the
next then [overlong] to the IO-APIC inside the southbridge.
The memory bus runs from the DIMMs to the Northbridge where
SDRAM signals are buffered before being fed to the CPUs.
But just because I can't see memory affecting the APIC doesn't
means it doesn't. It just means I can't see :)
I did get some nice Crucial/Micron ECC SDRAM for Xmas, and
I will have to unpatch my kernel (to restore the APIC error
msgs) and see if I get fewer.
-- Robert author `cpuburn` http://users.ev1.net/~redelm
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
