so, this happens on real hardware for you?
i could reproduce this with a linux virtual machine on vmware - whenever i suspended the windows host with a linux vm running in vmware, after resume the linux vm showed exactly this issue.

after some investigation i found, that it would recover from that state after some time - and the time needed for recover was (more or less) proportional to that time the host was in suspend(hibernate) state.
also see http://marc.info/?l=linux-kernel&m=120186717701371&w=2
i thought that was vmware related and i gave a bug report to dan hecht - i didn`t hear anything since then, but i think it`s worth CC`ing him.
not sure if

[PATCH 1/2] Introduce clocksource_forward_now -> http://marc.info/?l=linux-kernel&m=120716471203567&w=2

[PATCH 2/2] Introduce CLOCK_MONOTONIC_RAW -> http://marc.info/?l=linux-kernel&m=120596518521892&w=2

is related ? (also CC`d the patch authors, they will probably know)
regards

roland
List:       linux-kernel

Subject:    Clock has stopped (time/date looping over 5 seconds), things are

From:       Roger Heflin <rogerheflin () gmail ! com>

Date:       2008-04-04 21:27:11

Message-ID: 47F69D2F.8010607 () gmail ! com

[Download message RAW]
So far what I have is that the clock is moving between

10:01:03 to 10:01:07 (when it gets to 07 it goes back to 03), doing rdate -s

results in things changing:
16:12:38 to 16:12:43 (resets back to :38).
Doing this:

while true ; do date; usleep 1000000; done

Fri Apr  4 16:12:39 CDT 2008

Fri Apr  4 16:12:40 CDT 2008

Fri Apr  4 16:12:41 CDT 2008

Fri Apr  4 16:12:42 CDT 2008

Fri Apr  4 16:12:43 CDT 2008
It stops at :43, ^C is required, and you can then restart it with repeatable

results.
This F7 - 2.6.23.15-80.fc7
dmesg/messages contain nothing abnormal.
This machine has done it several times, a freqency of maybe 1x per every couple

of weeks or so.   I believe it had also done this with: 2.6.22.9-91.fc7 so it

has been doing this for a ...
[ message continues ]

This is real hardware, it is a always on desktop MB machine, nothing too weird,

right now I am putting 2.6.24.4 on it, and we will see in a few weeks if it does

it again.
I am getting it fairly consistently, so any ideas of what to turn on, or watch

for in the next event would be useful.    I did try collect several samples of

information from /proc of things that looked useful, the most telling thing I

found was that it appeared that in /proc/timer_list
now at 7300171087468 nsecs (number was different).
was actually looping similar to the time/date and not rising as it should have

been, this is a 32 bit on an AMD Sempron(tm) Processor 3400+, it is 64bit

capable. I did have files that containing several samples of /proc/timer_list,

but apparently the alt-sysrq-s then u before the b failed to save the

information or the general state of the machine was just so bad that it did not

get written out to disk, the last 2 times I have had this happen, it completely

failed to shutdown gracefully and s-u-b at least enabled me to force a reboot

without having to go to the machine and power cycle it.
 From previous data, the shortest time is 14 days 11 hours, and the longest is

about 23 days.
                                Roger
--