All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ed Smith <esmith@virtualiron.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Xen Devel <xen-devel@lists.xensource.com>,
	Steven Hand <Steven.Hand@cl.cam.ac.uk>
Subject: Re: Testing status of HVM (Intel VT) on 64bit XEN unstable c/s 11616
Date: Tue, 26 Sep 2006 14:31:12 -0400	[thread overview]
Message-ID: <451971F0.4090702@virtualiron.com> (raw)
In-Reply-To: <C13F13C0.1AA6%Keir.Fraser@cl.cam.ac.uk>

Keir Fraser wrote:
> On 26/9/06 16:33, "Ed Smith" <esmith@virtualiron.com> wrote:
> 
>>> any chance you can test with debug=y ? The back-traces aren't
>>> really very useful otherwise.
>> These are automated builds and tests that run each night.  We don't
>> normally build a debug XEN as we try and test the bits a customer
>> would run.  If these backtraces are useful in the release build how
>> will we diagnose crashes on a customer's site?
> 
> They take more deciphering, sometimes with the aid of the xen-syms file, as
> the backtrace contains functions that aren't really in the call chain (and
> misses some that are). It's less time consuming with a debug build, and
> there's less reliance on the xen-syms file, as we include frame pointers.
> 
> Trying to match customer bits doesn't make sense. There is no customer for
> these bits! So why throw away debug info during development testing just
> because there are situations where debug info is not available? Is it
> considered good training for developers? :-)
> 
>  -- Keir
> 

Debug builds are fine and certainly easier to well, debug with, but they often
run slower than release builds and hide problems.  Humm... I wonder if thats
why you are not seeing this problem.  Also when we rely on debug builds to
diagnose problems we do not design in the ability to diagnose problems when
the bits are in customers hands.  'Good training for developers'?  No just
trying to work towards a released product that is easier to debug because
just enough debug-ability is built-in.

I'm building a debug build now and will post the results of booting a 64bit
HVM guest on it.  Hopefully that will help diagnose this problem.

Thanks,
Ed

  reply	other threads:[~2006-09-26 18:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-26 14:04 Testing status of HVM (Intel VT) on 64bit XEN unstable c/s 11616 Ed Smith
2006-09-26 14:42 ` Steven Hand
2006-09-26 15:33   ` Ed Smith
2006-09-26 16:19     ` Steven Hand
2006-09-26 16:28     ` Keir Fraser
2006-09-26 18:31       ` Ed Smith [this message]
2006-09-26 18:34         ` Keir Fraser
2006-09-26 20:26           ` Ed Smith
2006-09-27  9:29             ` Keir Fraser

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=451971F0.4090702@virtualiron.com \
    --to=esmith@virtualiron.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=Steven.Hand@cl.cam.ac.uk \
    --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.