|
Hi Keir & Jan:
Good news is, the patch for Xen panic bug works. Tests on two servers are running happily
for almost two days. I will stop test if it doesn't fail until tomorrow evening.
Appreciate for all help you and Jan offered.
Well, till now, I think I've collected enough information for VM hang problem to have a discussion
with you two. Basically, we have two situation of VM hang(Those VM are all HVMs, and all are able to
run well for some time before actually hung).
1. We have two VMs in this situation. And under this situation, what we know clear are
(1) The *times* column in "xm ls" command never changed after VM hangs
In below three VMs, E2EZYXVM-56-W2.786.92 is hang(its "times" 9339.3 freezed), and the other two work well.
E2EZYXVM-56-W1.786.92 2 1024 2 -b---- 29009.0
E2EZYXVM-56-W2.786.92 3 1024 2 ------ 9339.3
E2EZYXVM-56-W3.786.92 4 1024 2 -b---- 27538.6
(2) From Xenctx output it call trace is same, and never change on every xenctx run.
Call trace likes:
Call Trace:
[<80708a5a>] <--
[<f76f1789>]
[<85f3f1f0>]
[<861fb0e8>]
[<861fb370>]
[<80558188>]
[<f76f3c1f>]
[<861fb370>]
[<85f3f1f0>]
[<861fb0e8>]
2. We have another two VMS on this situation, what we know is
(1) The *times* column in "xm ls" command are much higher than other VMS, and become larger very fast
In below three VMs, E2EZYXVM-138-W5.827.92is hang(its "times" 58262.8 grows every seconds),
and the other two work well.
E2EZYXVM-138-W4.827.92 5 1024 2 r----- 27692.5
E2EZYXVM-138-W5.827.92 6 1024 2 r----- 58262.8
E2EZYXVM-138-W6.827.92 7 1024 2 r----- 26954.3
(2) From Xenctx output it call trace is same, and never change on every xenctx run.
Call Trace:
[<80708a66>] <--
[<f7c2f072>]
[<861fa9dc>]
[<805582a8>]
[<f7c318a5>]
[<861fa9dc>]
[<861fa9dc>]
[<861fa0e0>]
[<861faa08>]
In addition, we have another VM which is in black screen and hung. But there is no abnormal information
I can get form "xm li" and xenctx.
Early in this afternoon, I was trying to decode those back trace to get symbols (HVMS is windows XP) but failed.
I am wondering If I could trigger a Domain U crash, and have the dump analyzed on windbg. Basically I am trying
to find out what did VM do exactly before hung.
Looking forward to your suggestion, thanks.
> Date: Wed, 8 Sep 2010 06:11:07 -0700
> Subject: Re: [Xen-devel] Xen-unstable panic: FATAL PAGE FAULT
> From: keir.fraser@xxxxxxxxxxxxx
> To: tinnycloud@xxxxxxxxxxx; JBeulich@xxxxxxxxxx
>
> On 08/09/2010 02:03, "MaoXiaoyun" <tinnycloud@xxxxxxxxxxx> wrote:
>
> > Here is my plan. I hope I could find a way to make it reproduced eaiser(Right
> > now hang shows
> > in a very small possibility). Also, I will learn to use xentrace, xenanyle to
> > help locate the bug.
> > I wonder if there exists a way that I can dump the guest Domain info, or at
> > least find out
> > where VM hang on, or have the backtrace.
>
> There is a tool called xenctx in tools/xentrace/ directory. This will dump
> registers and stack for a specified domain and vcpu. I think it may even be
> able to dump symbolic call traces for Linux kernels, if youc an pass it th
e
> vmlinux file.
>
> -- Keir
>
>
| 
Home