linux-kernel - Re: 2.6.31-rc5 regression: x86 MCE malfunction on Thinkpad T42p

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: <alpine.DEB.2.00.0908171041160.20915@gandalf.stny.rr.com>
Date:	Mon, 17 Aug 2009 10:49:01 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Johannes Stezenbach <js@...21.net>
cc:	Ingo Molnar <mingo@...e.hu>,
	Robert Richter <robert.richter@....com>,
	Andi Kleen <andi@...stfloor.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: 2.6.31-rc5 regression: x86 MCE malfunction on Thinkpad T42p


On Tue, 11 Aug 2009, Johannes Stezenbach wrote:

> On Tue, Aug 11, 2009 at 12:13:07AM +0200, Johannes Stezenbach wrote:
> > On Mon, Aug 10, 2009 at 11:31:33PM +0200, Ingo Molnar wrote:
> > > * Johannes Stezenbach <js@...21.net> wrote:
> > > > 
> > > > Could the warning be caused by the cpufreq ondemand governor? ISTR 
> > > > that one should switch to the performance governor before doing 
> > > > any profiling, but I forgot for this test.
> > > 
> > > there might be a connection - it could in theory cause sched_clock() 
> > > transients and confuse the ring-buffer time-stamping.
> > 
> > I'll try tomorrow after a fresh boot if the warning also appears
> > with the performance governor.
> 
> Nope, cpufreq was not the culprit.  The "Delta way too big!"
> warning in rb_reserve_next_event() happens after suspend-to-RAM.

Yeah, the ring buffer expects the time delta of two different events on 
the same page to be less than 2^59 nanosecs apart. But something must have 
screwed things up, since 2^59 nanosecs is 6671 days (18 years).

Perhaps coming out of suspend to ram changes the timestamp? Does it reset 
the result of sched_clock?

-- Steve

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