[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] garbage registers when domain killed by xen


  • To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • From: Kip Macy <kip.macy@xxxxxxxxx>
  • Date: Sat, 7 May 2005 09:02:29 -0700
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sat, 07 May 2005 16:02:05 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nAIliYWmm1H9MKxsfbQNRIIXtZb42DOdtBiIBx8lZwGBbK9w15WrHJ41iFn4U8/5i8khBD+UK7dMEflkUEnZgEElpGtHfNeqr9kSa8oFpwGWblJUMXaGTmH4phYYF/XOzeoygJjR722ls9nm0vXESmtrPVOHSrraxMhrY/xlFPQ=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On 5/7/05, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> It's probably repeatedly reentering your p-f handler at address 0. 

Sounds about right.

> 
> Yes, we should just domain_crash() if we see a callback to address 0.

Your patch or mine? ;-)

> Even more helpful would be some extra crash context with an explanation
> (some way of stating it was a virtual 'double fault' of some kind), but
> I don;t know how you would represent that in a standard core dump file.

One could add a set of flags to the dump. They wouldn't be visible to
GDB, but we could have a core reading utility that could see it and
spit out some basic info about the crash. GDB wouldn't need it per se'
as it would look just like a SIGSEGV crash in an application.

                                           -Kip

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.