Ben -- OK. I ran it twice, as shown below, on my new Dell OptiPlex GX620 Mini-Tower: Intel Pentium 4 Processor 650 with HT (3.4GHz, 2M, 800MHz FSB). I'm running Dapper 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux As far as I can tell, the new information that -D reveals is that it gave the same number of seconds since 1969 both times, even though it says it '...got clock tick' after it says that the select() timed out. root@manche:~# hwclock -D hwclock from util-linux-2.12r Using /dev/rtc interface to clock. Last drift adjustment done at 1121000000 seconds after 1969 Last calibration done at 1121000000 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... select() to /dev/rtc to wait for clock tick timed out ...got clock tick root@manche:~# uname -a Linux manche 2.6.15-26-386 #1 PREEMPT Thu Aug 3 02:52:00 UTC 2006 i686 GNU/Linux root@manche:~# hwclock -D hwclock from util-linux-2.12r Using /dev/rtc interface to clock. Last drift adjustment done at 1121000000 seconds after 1969 Last calibration done at 1121000000 seconds after 1969 Hardware clock is on UTC time Assuming hardware clock is kept in UTC time. Waiting for clock tick... select() to /dev/rtc to wait for clock tick timed out ...got clock tick root@manche:~# I ran the above tests after I pulled the battery out of the motherboard, waited a few hours, put it back in, and reset all the BIOS options and rtc, just in case there was some sort of corruption there, as noted in other bug reports. It didn't make any difference. I'm glad you're upgrading the status of this bug to critical. I agree that it's pretty serious. I can't keep the machine's rtc synchronized with real time, which ultimately will make a variety of messes (e.g. CVS). Ben Collins