> > 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
