Re: Re: system freeze when processor.ko is loaded during boot

[Martin Wilck <mwilck@arcor.de>]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

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

Martin


[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 2747 bytes --]

From: "Jan Beulich" <JBeulich@novell.com>
To: "Martin Wilck" <mwilck@arcor.de>, "Jinsong Liu" <jinsong.liu@intel.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Cc: "Donald D Dugger" <donald.d.dugger@intel.com>, "Gang Wei" <gang.wei@intel.com>,"Xin Li" <xin.li@intel.com>, "Yunhong Jiang" <yunhong.jiang@intel.com>
Subject: Re: [Xen-devel] Re: system freeze when processor.ko is loaded during boot
Date: Thu, 31 Mar 2011 12:48:30 +0100
Message-ID: <4D94862E02000078000395D0@vpn.id2.novell.com>

>>> On 29.03.11 at 00:48, Martin Wilck <mwilck@arcor.de> 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 

logarithmic_accumulation
update_wall_time
do_timer(0x898d7)
tick_do_update_jiffies64
tick_sched_timer
__run_hrtimer
hrtimer_interrupt
timer_interrupt

(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).

Jan


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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