All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Garron <xen-devel@sce.pridelands.org>
To: Daniel Stodden <daniel.stodden@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"Xu, Dongxiao" <dongxiao.xu@intel.com>
Subject: Re: Making snapshot of logical volumes handling HVM	domU causes OOPS and instability
Date: Tue, 31 Aug 2010 14:06:40 -0400	[thread overview]
Message-ID: <4C7D44B0.9060105@sce.pridelands.org> (raw)
In-Reply-To: <1283246428.3092.3476.camel@ramone.somacoma.net>

On 08/31/2010 05:20 AM, Daniel Stodden wrote:
> If it were just some or more tasks hanging initially, and it's caught
> some wait state, then identifying the point where things broke can
> sometimes be quite straightforward. Doesn't seem to be the case
> here.

      True.  It's at least narrowed down to something with the way LVM/DM
and udev interact during creation and removal of snapshots since the
machine can run for days without incident until I start adding and
removing snapshots (of running HVM volumes).

> Okay. I guess that won't be simple to repro. I wonder what you are
> running in dom0. Distro and version, what you upgraded and what not,
> any customized software builds etc.

      I'm running Debian Squeeze (testing) and have included a full list
of installed packages (dpkg -l) in the text file referenced in some of
my previous e-mails, here:
http://www.pridelands.org/~simba/hurricane-server.txt

      I've also included the output of "ps -eH -owchan,nwchan,cmd" during
normal operations (not yet in the "crashed" state).

      I don't recall running any customized software builds on dom0.
It's a fairly bog standard Debian installation.  If I'm going to do
anything customized, I usually do it on a domU.

> Given the rate at which you reproduce this and because only the
> snapshots seem to trigger the problem, to me this looks more like an
> LVM/DM issue than pvops specific.

      That has crossed my mind.  The only reason that I suspected
anything to do with Xen or pvops was that it only seems to happen when
creating/removing a snapshot of an active, running HVM.  I can create
and remove snapshots of other volumes all day and not trigger the bug
(tested yesterday).  It would probably be impossible to trigger the bug
on a baremetal machine that's not running a hypervisor.

> Also, it might be worth trying to turn off udev and see whether that
> changes sth.

      I'm going to try to reproduce it on another, less critical machine
today, so I can poke at it a little more.  I'll let you know what I find.

-- 
Scott Garron

  reply	other threads:[~2010-08-31 18:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-28  1:22 Making snapshot of logical volumes handling HVM domU causes OOPS and instability Scott Garron
2010-08-30 16:52 ` Jeremy Fitzhardinge
2010-08-30 18:18   ` Scott Garron
2010-09-12  9:33     ` J. Roeleveld
2010-08-30 19:13   ` Daniel Stodden
2010-08-30 20:30     ` Scott Garron
2010-08-31  9:20       ` Daniel Stodden
2010-08-31 18:06         ` Scott Garron [this message]
2010-09-03  8:06           ` Scott Garron
2010-09-12  9:41             ` J. Roeleveld
2010-09-12 18:48               ` Scott Garron
2010-09-13  0:15                 ` Making snapshot of logical volumes handling HVM domUcauses " James Harper
2010-09-13  8:35                   ` J. Roeleveld
2010-09-13  8:33                 ` Making snapshot of logical volumes handling HVM domU causes " J. Roeleveld
     [not found]           ` <4C80ABA6.6000203@pridelands.org>
2010-09-03 15:40             ` Jeremy Fitzhardinge
2010-09-11 19:16               ` Scott Garron
2010-09-12  0:20                 ` Making snapshot of logical volumes handling HVM domUcauses " James Harper
2010-08-31  6:59   ` Making snapshot of logical volumes handling HVM domU causes " Xu, Dongxiao
2010-08-31  8:16     ` Scott Garron

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=4C7D44B0.9060105@sce.pridelands.org \
    --to=xen-devel@sce.pridelands.org \
    --cc=daniel.stodden@citrix.com \
    --cc=dongxiao.xu@intel.com \
    --cc=jeremy@goop.org \
    --cc=xen-devel@lists.xensource.com \
    /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.