lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 04 Apr 2008 21:06:50 -0500
From:	Roger Heflin <>
Subject: Re: Clock has stopped (time/date looping over 5 seconds), things
 are wrote:
> 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
> 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 ->
> [PATCH 2/2] Introduce CLOCK_MONOTONIC_RAW -> 
> is related ? (also CC`d the patch authors, they will probably know)
> regards
> roland

This is real hardware, it is a always on desktop MB machine, nothing too weird, 
right now I am putting 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists