Bug#493479: linux-image-2.6.26-1-amd64: RTC suggestions do not make kernel bootable

[David Witbrodt <dawitbro@sbcglobal.net>]

> > Are there any Debian-specific changes to the HPET source code, or is
> > the
> > problem directly from upstream?
> 
> No, there are no Debian-specific changes. But 2.6.26 uses the new rtc
> infrastructure, which may change things.

  OK, I read '/linux-source-2.6.26/Documentation/rtc.txt' and then tried
building a kernel for each of your suggestions below.

> You may check the following:
> 1. Disable RTC_CLASS, set RTC=y

  I had RTC_CLASS disabled already, but RTC=m.  I changed to RTC=y as
suggested.  The resulting kernel freezes just like the stock kernel.


> 2. Set RTC_CLASS=y, RTC_DRV_CMOS=y

  Setting RTC_CLASS=y causes RTC to disappear in 'make menuconfig', and 
that equates to RTC=n, as desired.  The resulting kernel still froze.

  Both of these test kernels were configured with HPET=y and HPET_MMAP=y.
Experiments last night with HPET=y and HPET_MMAP=n made no difference,
though without modifications to RTC* (they all had RTC=m).

  In short, unless some change is made to the sources, then any d-i CD
with 2.6.26 tried on hardware like this machine will freeze during boot.
Not even the MAGIC_SYSRQ tricks get a response.

  Do you have any other suggestions?
  Should I try building from kernel.org sources?  (I don't think it could
possibly make a difference... but if I did that, I could then justify
submitting the regression report to LKML myself instead of using the 
Debian Kernel Team as intermediaries.)

Thanks,
Dave W.