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] [day] [month] [year] [list]
Message-ID: <20071204093451.GA4541@elte.hu>
Date:	Tue, 4 Dec 2007 10:34:51 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jörn Engel <joern@...fs.org>
Cc:	Mark Lord <lkml@....ca>, Pavel Machek <pavel@....cz>,
	Mark Lord <liml@....ca>, Thomas Gleixner <tglx@...utronix.de>,
	len.brown@...el.com, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	rjw@...k.pl
Subject: Re: [BUG] Strange 1-second pauses during Resume-from-RAM


* Jörn Engel <joern@...fs.org> wrote:

> On Mon, 3 December 2007 01:57:02 +0100, Jörn Engel wrote:
> > 
> > After an eternity of compile time, this config does generate some useful
> > output.  qemu is not to blame.
> 
> Or is it?  The output definitely looks suspicious.  Large amounts of 
> code get processed within a microsecond, while update_wall_time() 
> appears to cause huge delays every time it is called: 
> http://logfs.org/~joern/trace
> 
> Does this output make sense or does it rather indicate some sloppiness 
> wrt. time in the qemu virtual machine?

not sure. It could be qemu being scheduled away? You could try to run 
qemu with nice -20 or so, to avoid getting preempted. If time lapses 
like this still show up:

 trace-cm 434   0D.h. 1008us!: do_timer (tick_periodic)
 trace-cm 434   0D.h. 1972us+: update_wall_time (do_timer)

 trace-cm 434   0D.h. 1008us!: do_timer (tick_periodic)
 trace-cm 434   0D.h. 1972us+: update_wall_time (do_timer)

then that could indicate a timekeeping weirdness, OR it could mean that 
qemu is simply very slow. (there could be timer hw access between those 
two function calls)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ