All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: "Sebastian Färber" <faerber@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Hard LOCKUP with 2.6.32.28 (maybe scheduler/tick related?)
Date: Mon, 31 Jan 2011 08:52:18 -0500	[thread overview]
Message-ID: <20110131135218.GA12173@redhat.com> (raw)
In-Reply-To: <AANLkTikk7ZyMFKTP=WuZR5QhJoEdmpCRy9BW=FiE160z@mail.gmail.com>

On Mon, Jan 31, 2011 at 12:05:58PM +0100, Sebastian Färber wrote:
> Hi,
> 
> i recently upgraded some servers from 2.6.32.9 to 2.6.32.28 and see
> frequent "hard lockups" on
> a few of them now. I've compiled a kernel with debugging support and
> enabled the "NMI Watchdog"
> to get more information.
> I've attached my .config and the stack traces from the nmi watchdog,
> captured via a serial console.
> To me it looks like there is some problem in run_posix_cpu_timers and
> the problem is also
> triggering WARNING: at kernel/sched_fair.c:979 hrtick_start_fair.
> 
> Note that the kernel is patched with grsecurity and i'm running CONFIG_NO_HZ.
> There were no problems with 2.6.32.9.
> Would be great if someone could have a look at this, i can provide
> more information if neccessary.

Your attached 'crash' details had another stacktrace first.  That one
shows the nmi_watchdog triggering because a spin_lock is spinning forever
in 'd_real_path'.  I couldn't find that code in any upstream tree, then
again I was too lazy to clone the stable trees.  So I don't know what the
exact problem is, but if you look through the git history of 2.6.32.28 and
revert things that relate to 'd_real_path', you can probably workaround
the problem for now, until someone who knows that stuff better than me can
give you a better answer.

Cheers,
Don

  reply	other threads:[~2011-01-31 13:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-31 11:05 Hard LOCKUP with 2.6.32.28 (maybe scheduler/tick related?) Sebastian Färber
2011-01-31 13:52 ` Don Zickus [this message]
2011-01-31 14:21   ` Sebastian Färber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110131135218.GA12173@redhat.com \
    --to=dzickus@redhat.com \
    --cc=faerber@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.