On Tue, Mar 16, 2010, Timo Schoeler wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus JohnS spake:
On Mon, 2010-03-15 at 19:13 -0700, Bill Campbell wrote:
I am seeing ``APIC error on CPU3: 60(60)'' warnings from dmesg periodically on a CentOS 5.4 box, kernel 2.6.18-164.11.1.el5. The CPU is an Intel(R) Atom(TM) CPU 330 @ 1.60GHz. I am not a hardware type, and don't have a clue what this means.
Try "noapic" on the kernel boot parameter. Also if that don't work out try "acpi=off"
Hi,
just jumpin' in: I too have an Atom-based machine which runs *rock solid* with ''noapic'' as parameter, and crashes without.
However, I've got another machine based on exactly the same hardware (board, CPU, memory, HD, everything) and the same BIOS config -- running flawlessly without the parameter given.
We have four boxes in small chassis (micro-atx?) with Atom processors that are having no problems. These machines are basically gateway boxes for small businesses and do OpenVPN tunnels inter-connecting three offices in Texas and one in Missouri.
The box in question is in a larger chassis that doesn't require a low-profile NIC. It's several months newer than the others so I don't know if they're the same main board.
This is occurring while an rsync-3.0.4 process is receiving data sent by a machine running rsync-3.0.7 (I just updated the CentOS box to rsync-3.0.7 since noticing that it was a bit dated). This is the only significant load on this machine at this time.
Maybe your running out of kernel threads and or APIC can't distribute interrupts across the CPU. Or APIC don't like your motherboard/cpu under stress.
My impression was that it was not load (I tortured both machines running BOINC for a few weeks) but traffic. Thus, I suspect the (on board) NIC to be a bit... crappy (IIRC it was Realtek)? I've always wanted to test it with a reasonable NIC.
This shouldn't be on the on-board RealTek NIC, but on the Intel that's in a regular slot. On the other hand, when I look at the dmesg output it appears that it's the RealTek on the public NIC.
FWIW, after I updated this to rsync-3.0.7 yesterday afternoon, I restarted the rsync using -vP to monitor it, and it has been transferring without a glitch for 15 hours now.
Bill