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 at celestial.com 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