Comment 2 for bug 54621

Ok. The problem goes something like this:

This function is called to decide if the timer IRQ is "working".

static int __init timer_irq_works(void)
{
        unsigned long t1 = jiffies;

        local_irq_enable();
        /* Let ten ticks pass... */
        mdelay((10 * 1000) / HZ);

        /*
         * Expect a few ticks at least, to be sure some possible
         * glue logic does not lock up after one or two first
         * ticks in a non-ExtINT mode. Also the local APIC
         * might have cached one ExtINT interrupt. Finally, at
         * least one tick may be lost due to delays.
         */
        if (jiffies - t1 > 4 && jiffies - t1 < 16)
                return 1;

        return 0;
}

Note the use of mdelay(). Since we're testing the advancement of jiffies we can't use a jiffy-based timer. mdelay delays with a busy loop that runs a certain number of iterations based on the BogoMIPS rating of your machine.

The problem is that BogoMIPs are detected somewhat randomly on my laptop.

The "calibrating delay..." message always gets a value of about 3994.7 give or take a couple tenths. The message that comes later gets wildly different values on different boots.

[17179570.588000] Total of 2 processors activated (6485.23 BogoMIPS).

Depending on the BogoMIPS detected, the delay loop runs in much more or much less time and therefore too few or too many IRQs are detected while attempting to determine if the timer IRQ is connected, causing the test to fail.