Bug#493479: linux-image-2.6.26-1-amd64: can't see a quick fix in the sources

[David Witbrodt <dawitbro@sbcglobal.net>]

I've taken this search for a bugfix about as far as I can,
without outside help.  Nothing that I've tried has allowed
me to create a 2.6.26 kernel for my "fileserver" machine with
the boot parameter "hpet=disable".  That also includes the
stock 2.6.26-1 kernel.  (On my "desktop" machine, both stock
and custom 2.6.26-1 kernels boot just fine, though I do use
"notsc" on all of my machines to avoid annoying messages at
boot.)

Hoping that some simple change was made to the HPET sources
between 2.6.25 and 2.6.26 which I could manually revert, I
took a quick look for HPET-related files.  For example:

  find  linux-source-2.6.26  -name  '*hpet*'  -a \
        ! -path  'linux-source-2.6.26/debian*'

Most of the files listed had few or no changes between kernel
versions.  The most interesting results can be seen (if you
unpack 2.6.25-7 and 2.6.26-1 sources in the same directory)
with this command:

  diff -u linux-source-2.6.2[56]/arch/x86/kernel/hpet.c

This is what I saw:

===== BEGIN OUTPUT =====
--- linux-source-2.6.25/arch/x86/kernel/hpet.c    2008-04-16 22:49:44.000000000 -0400
+++ linux-source-2.6.26/arch/x86/kernel/hpet.c    2008-07-13 17:51:29.000000000 -0400
@@ -137,9 +137,10 @@
     hd.hd_irq[0] = HPET_LEGACY_8254;
     hd.hd_irq[1] = HPET_LEGACY_RTC;
 
-    for (i = 2; i < nrtimers; timer++, i++)
-        hd.hd_irq[i] = (timer->hpet_config & Tn_INT_ROUTE_CNF_MASK) >>
+    for (i = 2; i < nrtimers; timer++, i++) {
+        hd.hd_irq[i] = (readl(&timer->hpet_config) & Tn_INT_ROUTE_CNF_MASK) >>
             Tn_INT_ROUTE_CNF_SHIFT;
+    }
 
     hpet_alloc(&hd);
 
@@ -218,7 +219,7 @@
     hpet_freq = 1000000000000000ULL;
     do_div(hpet_freq, hpet_period);
     hpet_clockevent.mult = div_sc((unsigned long) hpet_freq,
-                      NSEC_PER_SEC, 32);
+                      NSEC_PER_SEC, hpet_clockevent.shift);
     /* Calculate the min / max delta */
     hpet_clockevent.max_delta_ns = clockevent_delta2ns(0x7FFFFFFF,
                                &hpet_clockevent);
===== END OUTPUT =====

At first I thought there might be an operator precedence bug with
the first change, at "&timer->hpet_config".  When I thought about
it more, I realized that the kernel works just fine on my "desktop"
machine.

At any rate, a kernel built with just the first change reverted
froze like the stock kernel; and a kernel built with both changes
reverted also froze.


Unless one of the tiny changes in the other files found with the
'find' command shown above, then the problem is not located in any
source files with "hpet" in their name.  That would mean that other
changes to the kernel are impacting HPET, and I simply don't have
the know-how (yet) to track down such bugs.


Dave W.