public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Rich, Jason" <jason.rich@tekcomms.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Panic at _blk_run_queue on 2.6.32
Date: Wed, 10 Jul 2013 22:27:29 +0200	[thread overview]
Message-ID: <20130710202729.GA18877@1wt.eu> (raw)
In-Reply-To: <636295BFF4A001418A00F46569A2CD2B161CE88B@US-PLNO-EXM01-P.global.tektronix.net>

Hi Jason,

On Tue, Jul 09, 2013 at 05:42:29PM +0000, Rich, Jason wrote:
> Greetings,
> I've recently encountered an issue where multiple hosts are failing to boot up about 1/5 of the time.  So far I have confirmed this
> issue on three seperate host machines.  The issue presents itself after updating 2.6.32.39 to patch 50 and patch 61.
> Both patch levels result in the failure described below.  Since this occurs on multiple hosts, I feel I can safely rule out hardware.

First, thank you for your very detailed report. Do you think you could narrow
this down to a specific kernel version ? Given that there are exactly 10
versions between .39 and .50, I think that a version-level bisect would take
3 or 4 builds (so probably around 20 reboots).

It would help us spot the faulty patch. Right now, there are 546 patches
between .39 and .50 so it's quite hard to find the culprit, even with your
full trace. That does not mean we'll immediately spot it, maybe a deeper
bisect will be needed, but it should be easier.

> It is also of note that I have not seen this behavior on the 3.4.26 kernel, or on any of my 32bit hosts.  

This is a good news, because we're probably missing one fix from a more
recent version that addressed a similar regression and that we might
backport into 2.6.32.62.

> That said, I have to support this software release (which runs on the 2.6 kernel) for at least another two years.  

Be careful on this point, 2.6.32 is planned for EOL next year :

   https://www.kernel.org/category/releases.html

You might want to consider migrating to a supported distro kernel or
to 3.2 instead. That said, if you follow carefully the updates from
later kernels, you might prefer to maintain your own backports of
the patches that are relevant to your usage.

Best regards,
Willy


  reply	other threads:[~2013-07-10 20:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-09 17:42 Panic at _blk_run_queue on 2.6.32 Rich, Jason
2013-07-10 20:27 ` Willy Tarreau [this message]
2013-07-15 14:09   ` Rich, Jason
2013-07-19 14:38     ` Rich, Jason
2013-07-22  9:03       ` Willy Tarreau
2013-07-22 21:15         ` Rich, Jason
2013-07-24 21:29           ` Rich, Jason
2013-07-24 21:48             ` Willy Tarreau
2013-07-24 21:55               ` Willy Tarreau
2013-09-10 18:04   ` Rich, Jason
2013-09-10 19:15     ` Willy Tarreau
2013-09-10 20:45   ` Rich, Jason

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=20130710202729.GA18877@1wt.eu \
    --to=w@1wt.eu \
    --cc=jason.rich@tekcomms.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox