Today’s agenda, a custom Linux kernel for a new Intel D945GCLF-based system. Something in Gentoo’s default generic kernel caused the system to oops on boot, compiling a tailored kernel should fix that. PLD Linux Rescue disc boots correctly on the system though, so we can chroot into the Gentoo system and build a new kernel.
More problems duly follow. What processor type should it be compiled for? Although similar to the Intel Core family (it shares their processor family value of 6), it is a very different processor. And of course, there isn’t a kernel option for the Core family anyway (only Core 2 Duo, a very different beast again). The feature set for the new Atom processors is pretty complete though:
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel® Atom™ CPU 230 @ 1.60GHz stepping : 2 cpu MHz : 1596.126 cache size : 512 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3195.18 clflush size : 64
Did I forget to mention that it supports HyperThreading? Or EM64T? Being as my previous system was 32-bit it was easier to migrate to the same, but a future 64-bit Linux machine is very possible. So we have everything short of SSE4 really, that doesn’t really narrow the field much. Following the earlier problems, it seemed prudent to err on the side of caution here; opting for
Pentium M as the processor type. It’ll be interesting to see what the recommendation becomes once more people have tried this.
Configuring everything else was reasonably straightforward, compilation went smoothly (not at full speed, the PLD Linux kernel is uniprocessor only), installation followed and then another reboot.
Our survey said uh-uh. Another crash, this time an oops in the Realtek
r8169 driver for the Ethernet card. Although the sources list the RTL8101E as a supported variant, on this board it locks up hard. Back to square one. Same old routine… Spare Belkin F5D5005 gigabit Ethernet card in the PCI slot, PLD Linux, chroot, modify the configuration, rebuild, install, reboot…
More promising. As far as a login prompt this time. Some startup services complaining but nothing too drastic (ALSA, lm_sensors, hardware-related stuff). Log in, OK let’s run some benchmarks get an idea of how fast this is…
Very, very slow. Or more like s-l-o-w watching characters appear on the display like a teletype terminal. Something is wrong here, check
htop to see what’s going on. Eventually. It took five minutes to load
htop. When it did all became clear: both processors (HyperThreading, remember?) running at 100% doing, err, surely that can’t be correct?
kacpid_notify between them were bringing the processor to its knees.
Now this has been seen before. Try searching for
kacpid linux slow or similar on your search-engine-du-jour and you’ll find that this isn’t an Atom-specific problem at all. There are a lot of buggy ACPI BIOS setups out there it seems, and this may just be another one for the list. Conventional wisdom seems to be to simply add
acpi=off to the kernel command line. Testing this proves the source of the error, with
acpi=off there are no more lock-ups and no rogue
kacpid. Because it isn’t running. And neither is HyperThreading. Or anything else ACPI-dependant. A solution of sorts, but far from perfect.
There is, however, another ACPI setting that may help here. Replacing
acpi=ht enables enough of the ACPI code to allow HyperThreading, but not the full ACPI feature range. A quick change in GRUB and another reboot later… HyperThreading is back, and the system boots successfully.
Will it remain stable?