I beleive that question was answered:

> The problem hinges around the fact that the FPU test disables the timer interrupt.
> No idea why. 

From http://www.intel.com/procs/support/pentium/fdiv/replqa3.htm:
Q3: What speeds of the Pentium  processor are affected by the floating point flaw?
A3: If you have a 60, 66, 75, 90 or 100MHz Pentium  processor, it is possible you may be affected with the floating point flaw. To check if you are affected, use CPUID. Any speeds higher than 100MHz do not have the FPU flaw.

Don´t blame me, but sorry Jim, but you are wrong. Direct from the kernel-sources:

if (mca_pentium_flag) {
                /* The IBM Model 95 machines with pentiums lock up on
                 * fpu test, so we avoid it. All pentiums have inbuilt
                 * FPU and thus should use exception 16. We still do
                 * the FDIV test, although I doubt there where ever any
                 * MCA boxes built with non-FDIV-bug cpus.
---------
printk("mca-pentium specified, avoiding FPU coupling test... ");
        if (!boot_cpu_data.fdiv_bug)
                printk("??? No FDIV bug? Lucky you...\n");
        else
                printk("detected FDIV bug though.\n");
        return;
        }
---------
See bugs.h for more details.

Greetings,
Stephan

Exception 16?
   The snippet of code inferrs that it was intended to test for the bug, and give either thumbs up or down, but not lock up. Why does (!boot_cpu_data.fdiv_bug) fail?

        /*
         * check if exception 16 works correctly.. This is truly evil
         * code: it disables the high 8 interrupts to make sure that
         * the irq13 doesn't happen. But as this will lead to a lockup
         * if no exception16 arrives, it depends on the fact that the
         * high 8 interrupts will be re-enabled by the next timer tick.
         * So the irq13 will happen eventually, but the exception 16
         * should get there first..
         */

This comment is in a fuction that is called before the one that says it's "Checking 'hlt' instruction...".  I'm wondering if the high 8 interrupts get re-enabled (and therefore the IRQ 13) *before* the exception 16 arrives, and when the asm code that actually does the HLT is executed, the system hangs.

I haven't been through all the code yet, just bugs.h, so this is just a guess . . . .