This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boo

To: Haitao Shan <maillists.shan@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boot
From: Martin Wilck <mwilck@xxxxxxxx>
Date: Sun, 03 Apr 2011 15:46:10 +0200
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Sun, 03 Apr 2011 05:54:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTimmXHe2W00++wCmQRTRmOd37MvsPqqQ0191wCc7@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Openpgp: id=70700BF2
References: <4CAF794F.6070308@xxxxxxxx> <4CBEAEE2020000780001E237@xxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E1E7146599A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D910C24.5090908@xxxxxxxx> <AANLkTimmXHe2W00++wCmQRTRmOd37MvsPqqQ0191wCc7@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110221 SUSE/3.1.8 Thunderbird/3.1.8
On 03/31/2011 08:23 AM, Haitao Shan wrote:

> I have checked your dump info via debug key. I saw that the EIPs
> remained the same between two successive dump. However, without the
> symbols I could not identify which code kernel was hanging on. Is it
> possible that you can find this information by disassembling the kernel
> binaries (with symbols). 

I think  Jan did just that already, I am attaching his analysis again.

> Or could you please repeat your test using an
> upstreaming Xen and kernel so that I could compile a same kernel just as
> you would be using?

Can do that but it needs some time.

> And I see you CPU is a very old model, UP without 64 bit support and no
> PAE? Right?

It has PAE, but it is UP and has no 64bit nor VT-x.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 2.13GHz
stepping        : 8
cpu MHz         : 800.000
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2
bogomips        : 1596.45
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 32 bits virtual


--- Begin Message ---
To: "Martin Wilck" <mwilck@xxxxxxxx>, "Jinsong Liu" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boot
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 31 Mar 2011 12:48:30 +0100
Cc: "Donald D Dugger" <donald.d.dugger@xxxxxxxxx>, "Gang Wei" <gang.wei@xxxxxxxxx>,"Xin Li" <xin.li@xxxxxxxxx>, "Yunhong Jiang" <yunhong.jiang@xxxxxxxxx>
In-reply-to: <4D911044.8000306@xxxxxxxx>
References: <4CAF794F.6070308@xxxxxxxx> <4CBEAEE2020000780001E237@xxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E1E7146599A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4D910C24.5090908@xxxxxxxx> <4D911044.8000306@xxxxxxxx>
>>> On 29.03.11 at 00:48, Martin Wilck <mwilck@xxxxxxxx> wrote:
> Here is one more capture. It shows that (unfortunately) clocksource=pit
> doesn't help here, and that the xen watchdog hits if I configure it
> (just that the reboot doesn't work, and I can only see the output since
> I've been using the serial console).

The stack evaluates to 


(matches the previously sent one, just that there the tick count
passed to do_timer() is "only" 0x179ab.

So the kernel, afaict, is busy recovering from the time jump in Xen.

It is clearly also a bad sign that the NMI hit while Dom0 was
executing, as that guarantees interrupts aren't disabled (and
hence timer interrupts can occur, and timers would not be
prevented from running - presumably the time jump suppressed
the invocation of, among others, the NMI timer).


--- End Message ---
Xen-devel mailing list