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
--
INTERNET: bill@xxxxxxxxxxxxx Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186 Skype: jwccsllc (206) 855-5792
Property must be secured, or liberty cannot exist. -- John Adams
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
