lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 31 Jul 2007 11:43:09 +0700
From:	Vasily Averin <vvs@...ru>
To:	john stultz <johnstul@...ibm.com>
CC:	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, devel@...nvz.org,
	Thomas Gleixner <tglx@...utronix.de>,
	George Anzinger <george@...sta.com>
Subject: Re: [2.6.22] negative time jump

john stultz wrote:
> On 7/29/07, Vasily Averin <vvs@...ru> wrote:
>> I've investigated why my testnode freezes. When I found that node is freezed
>> again I've started to press Sysrq keys and noticed the following negative time jump.
>>
>> Could anybody please help me to understand the reasons of this issue?
>>
>> --- VvS comment: some pre-history: node boot
>> Jul 27 13:58:10 ts28 Linux version 2.6.22 (vvs@....work.ve) (gcc version 3.4.6
>> 20060404 (Red Hat 3.4.6-3)) #11 SMP Fri Jul 27 12:47:45 MSD 2007
>> Jul 27 13:58:10 ts28 Command line: ro root=LABEL=/1 console=ttyS0,115200
>> console=tty debug silencelevel=8 crashkernel=128M@...M acpc=noirq clocksource=tsc
> 
> clocksource=tsc?
> 
> I suspect you're forcing the clocksource as its not selected by
> default. Could you provide dmesg output without that option. It might
> shed some light as to why the clocksource isn't chosen.

Default clocksource was acpi-pm. But the node have similar behavior when I've
used this clocksource. (please look at the following logs)

Originally I've investigated SATA-related issue and noticed some strange with
timers. When I've reproduced situation again I've pressed Alt+Sysrq+Q keys and
noticed that it shows incorrect time (it shows 431968 sec from booting but
according to the serial console timestamps it should be ~445954 sec). Then you
can see that time was jumped back, next timestamp is 431965 sec, 3 sec back.

> It may very well be your TSCs are not synched or are otherwise not
> reliable for timekeeping , and thus time is not consistent between
> cpus.

However IMHO it cannot explain time loops (~4400 sec) that I'm observing right now.

thank you,
	Vasily Averin

PS. You can look at the other logs and find more details in my attachments to
http://bugzilla.kernel.org/show_bug.cgi?id=8650


View attachment "ttt1.log" of type "text/x-log" (28920 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ