Bigmomma gets a whiff of Sulphur
I know I always had such a loyalty to Fedora Core 4 despite how outdated it was, but I finally decided it was time to move on.
On Saturday I had to replace another broken ceiling lamp in my basement and decided it would be a good time to install Fedora 9 on Bigmomma, since the power was going to be turned off anyway. So I did the usual and expected round of backups and let ‘er rip.
I installed Fedora 9 from the Live CD. That was the fastest damned OS installation I’ve ever seen – even against Ubuntu. It was incredible. And it still gave me the full slew of partitioning options that I’ve come to expect from Anaconda. Nice work, guys! Of course I did a massive groupremove on GNOME and X11 followed by a highly selective reinstall of just enough components to use system-config-bind over SSH X11 forwarding just as soon as the system was installed.
After configuring Apache I noticed that some Enano-based pages were taking 6-7 seconds to generate after the first couple of requests. How could this be, if FC4 generated 1.0 pages in 0.6 seconds and 1.1 pages in 0.3? So I got to work looking for something that might be slowing down or overburdening the CPU. What I found was quite a shock. It turns out that my CPUs in Bigmomma are not identical.
/proc/cpuinfo tells me that CPU0 is stepping 3, and CPU1 is stepping 6. There are no other immediate differences in there, but digging through /proc/acpi yielded a peculiar result: CPU1 supports throttling; CPU0 does not.
Why wouldn’t this bug have been triggered under FC4? Turns out that the BIOS fails the cutoff year for ACPI support – 2001 – under the FC4 kernel. But this cutoff date was removed in a later version of the kernel, roughly 2.6.17, and replaced with “real” ACPI detection.
The result? CPU1 was being throttled to as little as 7% of its real processing power while CPU0 continued working at full speed.
What I have to wonder is how this didn’t just completely panic the system, or perhaps even why does the system even boot in the first place? Maybe Linux’s SMP support is just too good. Well, I went into GRUB’s config and added “acpi=off” to the boot command line and rebooted, and voila – the age-old CPU lockup problem disappeared, just like that. Not like a server really needs ACPI anyway.
So that’s my latest Linux adventure. We’re all back up now (and even better: now we have IPv6 connectivity through tunnelbroker.net) and I’m hoping things will stay that way for a while.