I have a similar problem on a Dell Optiplex GX280. I have been doing some
extensive research on this problem, and I'd like to share what I've found.
The problem is definitely the HPET (High Precision Event Timer).
See http://en.wikipedia.org/wiki/High_Precision_Event_Timer for more
information on the HPET.
Check your boot log with dmesg|less. If you see a message that starts with
ACPI: HPET ...
Then your machine has an HPET and you will have this problem. Booting
with the kernel boot parameter
acpi=off
causes the HPET to not be recognized, and therefore the RTC module can
grab IRQ 8. But booting with acpi=off causes a lot of other devices to
not be recognized and/or configured too. And that's usually not good.
The problem is that both the HPET and the legacy RTC want to use IRQ 8.
And with Etch (2.6.18 kernel) and earlier releases, the kernel does not
allow IRQ 8 to be shared between the HPET and the RTC. I haven't tried
Lenny, with it's 2.6.26 kernel, and for reasons I don't want to get into,
I'm not going to. But the long term solution is for the kernel to allow
IRQ 8 to be shared between the HPET and the legacy RTC. Of course, the
hardware itself has to allow interrupt sharing too, or there's not much the
kernel can do about it.
If the hardware doesn't allow interrupt sharing, perhaps the kernel people can
write a replacement for the RTC driver that emulates a legacy RTC using the
HPET. But with Etch at least, here are the alternatives that I have found:
1. Configure a custom kernel that has all support for the HPET disabled.
When you're all done, look through the .config file and make sure that all
configuration options containing the character string HPET are commented out.
If not, you missed something. Go back and try again. Unlike the RTC
driver, which can be made a module, support for the HPET is built into the
kernel. This will allow full use of the legacy RTC driver, whether it is
built in to the kernel or whether it is a module. Of course, the HPET
cannot be used at all. This was my solution.
2. In some cases, you may be able to use the genrtc driver rather than the
rtc driver. The genrtc driver emulates interrupts in software. To do this,
add genrtc to /etc/initramfs-tools/modules and run update-initramfs -uv.
Then shutdown and reboot. genrtc cannot emulate all the functions of the
legacy rtc driver.
3. Another option (with Etch anyway) is using the CONFIG_HPET_RTC_IRQ=y
option when you build a custom kernel. This tells the legacy rtc driver
to assume that the HPET has stolen IRQ 8 and to not use interrupts.
This allows the kernel to use the HPET. However, the legacy RTC driver
has reduced function this way.
4. As mentioned earlier, forcing the use of the --directisa option in
hwclock, either through a wrapper or by editing the hwclock.sh script, may be
sufficient.
5. Finally, there's acpi=off as a last resort.
Again, the long term solution is interrupt sharing. If this cannot be done,
then perhaps Debian should consider changing their stock kernel to not
include HPET support. Users who need HPET support would then have to
build their own custom kernel and deal with the RTC issue somehow.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
