linux-kernel - Re: mm snapshot broken-out-2007-04-25-02-49.tar.gz uploaded

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]

Message-Id: <200704252248.03243.ak@suse.de>
Date:	Wed, 25 Apr 2007 22:48:03 +0200
From:	Andi Kleen <ak@...e.de>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: mm snapshot broken-out-2007-04-25-02-49.tar.gz uploaded

On Wednesday 25 April 2007 22:42:44 Jeremy Fitzhardinge wrote:
> Michal Piotrowski wrote:
> > Timing information is broken
> >   
> 
> This looks like Andi's sched_clock stuff hitting: it returns an
> inherently per-cpu result, so using it for printk timestamps isn't very
> useful.

It should actually roughly work. There can be some drift, but there shouldn't
be that much error. All CPUs should tick at roughly the same rate because
it's scaled to nanoseconds

If the drift is a big issue it would also be possible to resync every minute
or so, but I haven't implemented that.

There will be always some minor monotonicities because it won't try
to stop the CPU from reordering instructions.

I don't know why it is that off in your case.

 
> > [4294667.511000] BUG: at arch/i386/kernel/sched-clock.c:175 init_sched_clock()
> > [4294667.511000]  [<c01052e0>] dump_trace+0x63/0x1eb
> > [4294667.511000]  [<c0105482>] show_trace_log_lvl+0x1a/0x30
> > [4294667.511000]  [<c01060c4>] show_trace+0x12/0x14
> > [4294667.511000]  [<c0106161>] dump_stack+0x16/0x18
> > [4294667.511000]  [<c04fd968>] init_sched_clock+0x6d/0xcc
> > [4294667.512000]  [<c04f8505>] kernel_init+0x14e/0x2bf
> > [4294667.512000]  [<c0104ec3>] kernel_thread_helper+0x7/0x10
> > [4294667.512000]  =======================
> 
> This also seems to be the sched_clock change; the WARN_ON is asserting
> that it got initialized early enough, but it isn't. 

That's already fixed.

-Andi


-
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/