[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <473F88B0.1030309@goop.org>
Date: Sat, 17 Nov 2007 16:34:56 -0800
From: Jeremy Fitzhardinge <jeremy@...p.org>
To: Greg KH <greg@...ah.com>
CC: David <david@...olicited.net>, Ingo Molnar <mingo@...e.hu>,
gregkh@...e.de, Javier Kohen <jkohen@...rs.sourceforge.net>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [stable] Soft lockups since stable kernel upgrade to 2.6.23.8
Greg KH wrote:
> Great, thanks for tracking this down.
>
> Ingo, this corrisponds to changeset
> a115d5caca1a2905ba7a32b408a6042b20179aaa in mainline. Is that patch
> incorrect? Should this patch in the -stable tree be reverted?
>
Hm, I've never observed a problem with this in mainline.
Ah. The significant difference between 2.6.23 and -git is that the
former used sched_clock as the softlockup timebase, versus cpu_clock in
git. If sched_clock() is tsc-based, and the tsc isn't stable when using
cpufreq, then the softlockup with get confused and fire spuriously.
Ingo's fix to reporting exposed the fact that softlockup is terminally
broken in that kernel.
I think the best course for now is to revert it, since softlockup is
hardly a critical feature. The proper fixes would either be to backport
cpu_clock() to 2.6.23, or make it go back to using ticks.
J
-
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