[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1183699046.3289.51.camel@chaos>
Date: Fri, 06 Jul 2007 07:17:26 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Ernie Petrides <petrides@...hat.com>
Cc: Chris Friesen <cfriesen@...tel.com>,
Clemens Koller <clemens.koller@...gramm.de>,
Chris Wright <chrisw@...s-sol.org>,
Uli Luckas <u.luckas@...d.de>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.21.5 june 30th to july 1st date hang?
On Thu, 2007-07-05 at 19:12 -0400, Ernie Petrides wrote:
> On Thursday, 5-Jul-2007 at 16:49 MDT, Chris Friesen wrote:
>
> > Ernie Petrides wrote:
> >
> > > Only kernels built with the CONFIG_HIGH_RES_TIMERS option enabled were
> > > vulnerable.
> >
> > As I mentioned in my post to Thomas, we have high res timers disabled
> > and were still affected. Granted, our kernel has been modified so it is
> > possible that vanilla would not be affected....I haven't tested it.
> >
> > Chris
>
> That's odd, because Thomas's patch removed two calls to clock_was_set(),
> which is a no-op when CONFIG_HIGH_RES_TIMERS is not enabled (at least in
> the 2.6.21 source tree).
>
> Also, I personally tested with the reproducer you posted here, initially
> on a box running 2.6.22-rc4, and there were no problems (but I'm not sure
> what config options were enabled on that kernel). I did reproduce the
> problem on a stock 2.6.21 kernel with CONFIG_HIGH_RES_TIMERS enabled.
It needs a running smp_call_function() to be interrupted by the timer
interrupt, which calls clock_was_set(). So it's not that easy to
reproduce.
tglx
-
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