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
